Title: VBA, Visual Basic, Terminal Emulators: Which should I use?

Issue: Spectrum May/Jun '99

Author: Nathan Rector

Company: Natec Systems

Email: nater@northcoast.com

http: www.northcoast.com/~nater/

"Why should I use VBA? Why should I use VB? Do I need to change?" These were questions that I ran across several times at the 1999 Reno Spectrum Show.

The main consensus that I ran across was the Visual Basic and Visual Basic for Applications make things look nice, but why would you use them? Why would you move away from the typical "dumb terminal" applications? Why would you use Visual Basic or VBA instead of using a terminal emulator that allows a developer to create GUI screens by just replacing CRT and INPUT statements with BASIC calls?

Let's start with Visual Basic for Applications. As I've mentioned in previous articles, Visual Basic for Applications allows developers to extend, restrict, or alter the functionality of Microsoft Office (or any other program that is VBA aware). VBA allows developers to keep the code with the original documents, so when the document is moved from one machine to another, all extension, restrictions, and alterations are transferred with it.

Visual Basic allows developers to create true Windows programs. When using Visual Basic, developers are allowed to access other Windows programs; for example, start them, stop them, pass them information. Visual Basic also allows you to add third party modules that allow developers to display or analiyize information from their Multivalue Database, or automatically retrieve information from the Internet or Relational Database.

Windows programs give developers the ability to display information in more than one format. It can be displayed in graphs, or with color highlights for key and missing information, or just the ablility to display more information with different fonts.

Terminal Emulators with the ability to call subroutines to display GUI front ends are really nice tools. They definitely have their place when planning to move from dumb terminals to GUI front ends. Terminal Emulators give developers the ability to alter a few key parts of an existing BASIC program, such as INPUT and CRT, to create a GUI screen. Very little to nothing about the program has to be rewritten.

Another advantage to Terminal Emulators is that it is easier to mix and match dumb terminal applications with the modified routines with the GUI front end. They can also write everything in Multivalue BASIC without having to learn any new programming language. This makes development time lower than with Visual Basic or Visual Basic for Applications.

I've just talked about the advantages of Visual Basic, Visual Basic for Applications, and the use of Terminal Emulators. Now lets me go over the disadvantages of each.

Visual Basic for Applications is designed to allow manipulation of the applications it was included with. It is not designed to create independent Windows programs. If you use Visual Basic for Applications, you are writing the code to work with that application's objects and only that application will be able to use the code supplied. It's great for pulling data from an external source or customizing the application's working environment (e.g. menus and control buttons), but was never designed to work outside the application it supplied with.

Visual Basic allows you to create pure Windows programs, but that is its disadvantage as well. If a developer wants to use Visual Basic to replace their existing "dumb terminal" applications, they will have to rewrite them completely in Visual Basic. Even though Visual Basic is very much like MultiValue BASIC, there is still a small learning curve to go through.

Most of the MultiValue Objects, such as D3/Object, jBase/Objects, Winlink/Objects, and uvObjects, gives developers the ability to call existing BASIC programs on the MultiValue host, but this really only works well when trying to process existing "Business Rules" (e.g. Payroll Calculation programs or cross-reference updating programs). None of the BASIC programs can have INPUT statements in them since there is no way to process the INPUT statement without a terminal connection to the database.

As I said above, Terminal Emulators are a nice way to get a GUI screen without a large change. The problem is that they are limited in what they can do. Terminal Emulators can give you a GUI screen for input and maybe a few other things, but they are limited in how much functionality a developer can give the GUI application. They also lock you into that specific Terminal Emulator. If you want to move to a different one because it has more functionality or better suits your user's needs, then a developer has to rewrite all the existing code that specifically uses that Emulator.

Terminal Emulators don't always give developers a completely seamless connection between Windows applications and the multivalue database. All the Terminal Emulator give developers the ability to import and export data from the multivalue database, but are generally limited to importing and exporting into flat files. After the Import or Export, the user would then have to load the informatin into the Windows applications by hand. There is no seamless "when I open the application the data is loaded automatically" and "when I close the application the modified data is written back to the database automatically".

Now let's take actual examples:

Example 1:

The user wants to access MultiValue information in Excel. Management wants to make sure that any data modified in Excel is modified in the MultiValue database. They also want to keep some information in the Excel spreadsheet read only, while others they want to have regenerated when ever related information changes.

For this I would use VBA. It gives the developer the ability to fulling control how the data is used and updated when the user is in Excel.

Example 2:

Management wants to upgrade the look and feel of their "dumb terminal" applications. They want it done quickly and with as little changes as possible.

For this I would use a Terminal Emulator. They give you the flexibility of a simple GUI applications, as well as allowing the developers to alter existing BASIC programs quickly and easily.

Example 3:

Management wants to integrate data from multiple sources to be displayed in a single screen, or they want to connect together several Windows programs with their MultiValue data, such as Excel, a scanner, and UPS tracking information from the Internet.

For this I would use Visual Basic.

Example 4:

Management wants to replace their "dumb terminal" applications with GUI screens but they want to keep the existing business logic. They also don't want to use terminal emulators, or they just want to click on an Icon to start the application.

For this I would use Visual Basic.

Example 5:

Management wants all existing applications made into Windows Programs, but they don't want to move to a different database.

For this I would use Visual Basic

I have given a few examples that I have run across and what I've used in each case. Each way of creating GUI screens has its trade offs and advantages. Weigh all of them before choosing one over the other.

Title: VBA, Visual Basic, Terminal Emulators: Which should I use?

Issue: Spectrum May/Jun '99

Author: Nathan Rector

Company: Natec Systems

Email: nater@northcoast.com

http: www.northcoast.com/~nater/

"Why should I use VBA? Why should I use VB? Do I need to change?" These were questions that I ran across several times at the 1999 Reno Spectrum Show.

The main consensus that I ran across was the Visual Basic and Visual Basic for Applications make things look nice, but why would you use them? Why would you move away from the typical "dumb terminal" applications? Why would you use Visual Basic or VBA instead of using a terminal emulator that allows a developer to create GUI screens by just replacing CRT and INPUT statements with BASIC calls?

Let's start with Visual Basic for Applications. As I've mentioned in previous articles, Visual Basic for Applications allows developers to extend, restrict, or alter the functionality of Microsoft Office (or any other program that is VBA aware). VBA allows developers to keep the code with the original documents, so when the document is moved from one machine to another, all extension, restrictions, and alterations are transferred with it.

Visual Basic allows developers to create true Windows programs. When using Visual Basic, developers are allowed to access other Windows programs; for example, start them, stop them, pass them information. Visual Basic also allows you to add third party modules that allow developers to display or analiyize information from their Multivalue Database, or automatically retrieve information from the Internet or Relational Database.

Windows programs give developers the ability to display information in more than one format. It can be displayed in graphs, or with color highlights for key and missing information, or just the ablility to display more information with different fonts.

Terminal Emulators with the ability to call subroutines to display GUI front ends are really nice tools. They definitely have their place when planning to move from dumb terminals to GUI front ends. Terminal Emulators give developers the ability to alter a few key parts of an existing BASIC program, such as INPUT and CRT, to create a GUI screen. Very little to nothing about the program has to be rewritten.

Another advantage to Terminal Emulators is that it is easier to mix and match dumb terminal applications with the modified routines with the GUI front end. They can also write everything in Multivalue BASIC without having to learn any new programming language. This makes development time lower than with Visual Basic or Visual Basic for Applications.

I've just talked about the advantages of Visual Basic, Visual Basic for Applications, and the use of Terminal Emulators. Now lets me go over the disadvantages of each.

Visual Basic for Applications is designed to allow manipulation of the applications it was included with. It is not designed to create independent Windows programs. If you use Visual Basic for Applications, you are writing the code to work with that application's objects and only that application will be able to use the code supplied. It's great for pulling data from an external source or customizing the application's working environment (e.g. menus and control buttons), but was never designed to work outside the application it supplied with.

Visual Basic allows you to create pure Windows programs, but that is its disadvantage as well. If a developer wants to use Visual Basic to replace their existing "dumb terminal" applications, they will have to rewrite them completely in Visual Basic. Even though Visual Basic is very much like MultiValue BASIC, there is still a small learning curve to go through.

Most of the MultiValue Objects, such as D3/Object, jBase/Objects, Winlink/Objects, and uvObjects, gives developers the ability to call existing BASIC programs on the MultiValue host, but this really only works well when trying to process existing "Business Rules" (e.g. Payroll Calculation programs or cross-reference updating programs). None of the BASIC programs can have INPUT statements in them since there is no way to process the INPUT statement without a terminal connection to the database.

As I said above, Terminal Emulators are a nice way to get a GUI screen without a large change. The problem is that they are limited in what they can do. Terminal Emulators can give you a GUI screen for input and maybe a few other things, but they are limited in how much functionality a developer can give the GUI application. They also lock you into that specific Terminal Emulator. If you want to move to a different one because it has more functionality or better suits your user's needs, then a developer has to rewrite all the existing code that specifically uses that Emulator.

Terminal Emulators don't always give developers a completely seamless connection between Windows applications and the multivalue database. All the Terminal Emulator give developers the ability to import and export data from the multivalue database, but are generally limited to importing and exporting into flat files. After the Import or Export, the user would then have to load the informatin into the Windows applications by hand. There is no seamless "when I open the application the data is loaded automatically" and "when I close the application the modified data is written back to the database automatically".

Now let's take actual examples:

Example 1:

The user wants to access MultiValue information in Excel. Management wants to make sure that any data modified in Excel is modified in the MultiValue database. They also want to keep some information in the Excel spreadsheet read only, while others they want to have regenerated when ever related information changes.

For this I would use VBA. It gives the developer the ability to fulling control how the data is used and updated when the user is in Excel.

Example 2:

Management wants to upgrade the look and feel of their "dumb terminal" applications. They want it done quickly and with as little changes as possible.

For this I would use a Terminal Emulator. They give you the flexibility of a simple GUI applications, as well as allowing the developers to alter existing BASIC programs quickly and easily.

Example 3:

Management wants to integrate data from multiple sources to be displayed in a single screen, or they want to connect together several Windows programs with their MultiValue data, such as Excel, a scanner, and UPS tracking information from the Internet.

For this I would use Visual Basic.

Example 4:

Management wants to replace their "dumb terminal" applications with GUI screens but they want to keep the existing business logic. They also don't want to use terminal emulators, or they just want to click on an Icon to start the application.

For this I would use Visual Basic.

Example 5:

Management wants all existing applications made into Windows Programs, but they don't want to move to a different database.

For this I would use Visual Basic

I have given a few examples that I have run across and what I've used in each case. Each way of creating GUI screens has its trade offs and advantages. Weigh all of them before choosing one over the other.