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:
- Identify
discrete tasks and objectives.
- Review
standards to be applied.
- 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:
- 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.
- 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?
- 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)
- 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.
- 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.
- 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.
Distribution
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
