Ask the MultiValued Visual Basic Expert - #11B

(as published in Spectrum magazine Sep/Oct 1998)

To email your questions to "Ask the MultiValued VB Expert", click here.
Copyright 1996-98 Caduceus Consulting. All rights reserved.

Packaging a VB Application

Dear Andrew:

It was a pleasure talking to you again at the recent Spectrum conference. As always, I found your presentations very helpful.

I do have a couple of questions relating to VB which may even be worthy of discussion in your column:

My first question concerns ‘packaging’ a VB application. All of the examples of VB applications which I have seen have been fairly small - an Order Entry screen, for example. However, we developers generally deal with larger collections, such as a distribution system, where Order Entry would be only a small part. I have not found any discussion of, or guidelines for, packaging and distributing these larger ‘systems’. Surely there must be topics which must be considered. Can you shed some light on this topic?

My second question concerns the use of function keys. Microsoft seems to use them freely. I know we can detect the user pressing a function key in several places, such as the form KeyPress event (with KeyPreview enabled). Are there any traps we might fall into or things we should be aware of when using function keys?

As always, thanks for your assistance! - Ralph Justus, Rivendell Computer Systems

You’re absolutely right, Ralph. We Visual Basic trainers are constantly tossing around ye olde generic Order Entry screen, but the concerns that you bring up are rarely addressed. Thanks to you, I’ll give it a shot, although it’s a pretty big topic. (And there I was last issue daring you readers to come up with something a little more challenging!)

The ‘packaging’ of a large system can have a few meanings. Ignoring the issue of what kind of box the manuals and disks are shipped in, I’m going to assume that our first dilemma will be: what is this new system going to look like? What is the big picture? I will begin by summarizing a few of the procedures that I go through myself when putting together a new system in VB. These are usually:

  1. Identify discrete tasks and objectives.
  2. Review standards to be applied.
  3. Determine what is configurable.

Identify Discrete Tasks and Objectives

All systems development should start and end with the end-user, and VB systems are no exception. I classify Windows applications using terms coined by Alan Cooper (the original designer of Visual Basic, and thus a minor deity) in his book About Face – The Essentials of User Interface Design. Every application has what he calls a ‘posture’ (the way it presents itself to the user). The two most common are ‘sovereign’ and ‘transient’.

A sovereign application is usually the only one on the screen, and monopolizes the user’s attention for long periods of time. Typical examples are word processors and spreadsheets, but in fact it is rare that custom applications assume a sovereign posture. One relevant example from my experience is a screen that constantly monitored medical laboratory results and presented critical or STAT results to an operator whose sole job was to phone such results to the ordering physician. The operator would be in that screen all day to monitor all results to be phoned and to launch more detailed screens. A transient application, on the other hand, performs a single, well-defined function, and is called and dismissed as required. There are many more examples of custom transient applications, including our ever-familiar Order Entry screen. Transient programs are usually the equivalent of one or two menu entries from menu-driven legacy systems.

Speaking of menus, I have seen instances where developers have attempted to reproduce their legacy system menus in one big sovereign application using multi-leveled dropdown Windows menus. I believe that in most cases, this is a mistake, brought on by incorrect ‘morphing’ of like terms: a character menu is not the same as a Windows dropdown menu. In the Windows environment, it is the desktop that is the user’s primary ‘menu’, and program icons represent the menu entries. The Windows 95-style Start menu can also be used to reproduce some of that menu-driven functionality. Unless the creation of a sovereign application can be clearly justified, restricting each Visual Basic project to the performance of one or two simple objectives will mean smaller, faster code, and fewer development headaches.

Since most custom programming involves transient programs that represent single discrete tasks, the first step is to determine what those tasks are and how extensive they get in a typical user session. You can then determine how much can be performed by that one Visual Basic application versus the user having to open a separate application. I could write volumes on this topic alone, but Alan Cooper does a much better job – buy his book.

Review Standards to be Applied

Leaping from the big picture to some tiny details, I next discuss with systems management and users what interface standards are to be employed throughout the development. Those readers who have attended one of my seminars will recall that I cannot overemphasize the importance of following the established Windows standards – to ignore them cheats you of the biggest reason to develop in Visual Basic: instant user familiarity. However, there are many ways to go beyond the standards and lay down your own extensions. Here are some examples from my own experience:

  1. How are users to be informed of errors? An intrusive MsgBox is just that: intrusive. Highlighting problem fields and disabling the OK button until they are fixed is often preferred.
  2. What technique is to be used for looking up different kinds of information: Automatic lookups as the user types? Browse keys? Searches based on partial text?
  3. How is the Enter key to function? Are there instances where you want the Enter key to look up information and/or leave a field as opposed to simply clicking some default ‘OK’ button? (See this column in Jan/Feb 97 issue)
  4. Will all the background of all forms be Microsoft battleship gray? It is an assumed standard, but judicious use of color can give users faster feedback on exactly what module they are in. Another standard that I have used is to have a large graphic on every window which is a large version of that window’s icon. This reinforces the connection between the icon and the module.
  5. For a window with many text boxes, it is sometimes difficult to find the flashing line cursor. Consider highlighting the current text box with a pale colored background.
  6. Speaking of color, some clients prefer a different color for prompt/caption labels and labels containing actual data. Be aware though that you have to account for the fact Windows allows every user to change their default color scheme – which also happens to be the one that will be used by your application. If color is important, you might considered setting those colors explicitly.

Determine What is Configurable

Whether developing an application for one user or to be resold to many clients, sooner or later the user will want to change the way certain parts of the system work. The old Windows standard was to store configuration information in an INI file. The new standard with 32-bit applications is to use the Windows registry. If you make an attempt to determine up front what might be changeable later, you can save yourself a lot of grief and trouble. Fortunately, VB makes it very easy to not only store and retrieve configuration information, but also to make controls visible/invisible or enabled/disabled and to change captions based on that information.


The other part of your first question dealt with ‘distributing’ these systems. I’m not sure what you are referring to by that, but let’s look at two possible issues: Software installation and deployment. The final step of most Visual Basic applications is to compile them into a Windows executable (EXE) file. An end user would need a copy of this file, as well as several other standard VB run-time files in order to run your application. VB itself comes with a utility called the Setup Wizard which guides you through the process of creating an installation diskette for your application which will appropriately install all of the required files, including your executable. The resulting setup program is not the most sophisticated, but it generally does the job. Also, the setup program is itself a VB project that you can access and enhance if necessary. Better tools (such as the popular InstallShield) are widely available if you need a real professional looking result.

When it comes to deploying a VB application at a client site, I typically recommend that the programs reside on a central server that all required users can access. That way, if you have to make a change, you only have to do it in one place and everyone gets it. Of course, this also implies a reliance on a central system. When separate copies must exist on laptops and other standalones, I sometimes use a version checking system that will automatically alert the user to obsolete program versions.

Function Keys

Finally, you ask what tips I might have on the use of function keys in Visual Basic applications. I can only think of one function key standard: that of F1 for Help. As far as I know, Microsoft does not enforce any standards or grab events for particular function keystrokes, but if it ever did, keys like F1 would be the ones to avoid (unless of course you are using it for help!).

You mention one way of detecting function keys: using the KeyPress event. It is also possible to assign function keys to particular menu entries, thus letting VB invoke them automatically. Indeed, I know of some tasks that were put on dropdown menus almost exclusively to take advantage of this feature. To assign a function key shortcut, open up the VB Menu Editor (under the Tools menu), create a menu entry, and select one of F1 through F12 from the Shortcut dropdown combo box. Note that you can also select a Ctrl+Fn, Shift+Fn, or Ctrl+Shift+Fn shortcut.

To email your questions to "Ask the MultiValued VB Expert", click here.
Copyright 1996-98 Caduceus Consulting. All rights reserved.
Added: August 21, 1998.

Return to Caduceus Consulting Home Page

Copyright 2006 intellact
Last modified: Thursday May 25, 2006