Visual Basic/Idioms

An idiom is a sort of template or generic method of expressing an idea. In the same way that idioms in a human language make life easier for the both speaker and listener good idioms in computer programming make life easier for the programmer. Naturally what is idiomatic in one language might not be in another.

It is not necessary that there exist a physical template, an idiom can exist in your head and be so familiar that when faced with a problem that can be solved by application of an idiom you begin to type the code almost without noticing what you are doing.

Another word often used for ideas like this is pattern. However the word pattern has become so formalised and so strongly associated with object orientation that I feel the more generic word idiom is better also it is the word generally associated with the first major example that I will show.

An idiom can be language specific, library specific, domain specific, or any combination of the three. For instance if you are writing a program that deals with lists of things you might borrow some of the list processing idioms of Lisp even though Visual Basic Classic has no native list processing functions at all. By creating functions that manipulate lists rather than inlining the code to do it you will make your code more meaningful to someone reading it.

It is a commonplace that programmers feel ever so slightly godlike because they are in total control of their programs. I think that programmers would be better off emulating Shakespeare instead: when the English language of his day wasn't up to saying what he wanted he had no hesitation in extending both its stylistic range and its vocabulary.

The name of this idiom makes it sound like a very complicated idea but in fact it is very simple and fits Visual Basic Classic very well. This idiom is a solution to problems such as setting and clearing busy flags, controlling access to files, setting the mouse icon and so on.

The basic idea is to use the constructor of an object to obtain or query a lock on some resource and to use the destructor to release that lock. In a language like Visual Basic which has deterministic finalization this produces very succinct code.

It is very common in Windows programs to set the mouse icon to indicate that the program is busy and the the user must wait. A problem arises when you have lots of different pieces of code that can take a long time and lots of different code paths that invoke them. If the caller doesn't know that the process will be time consuming it won't know that the icon must be changed so we put code in the long running routine to change the mouse pointer. This works fine until we try to combine two or more such routines: which one gets to cancel the busy icon?

One common solution is to regard the mouse as a resource and control access to it with a pair of routines that maintain a count. One routine increments the count when the routine sets the busy icon and the other decrements and clears the icon when the count goes to zero. This works well until an exception occurs, then a routine might exit early and the routine that decrements the counter won't be called. Of course you could put another call in the error handler but that causes extra maintenance.

A better solution is to make use of the automatic termination events built in to Visual Basic. The basic idea is still to use a count but instead of guarding the count with a routine you guard it with an object.

Each procedure that wants to indicate that it is time consuming by showing the mouse busy icon should wrap its code in a with statement that creates a cMouseBusy instance by calling NewMouseBusy. When the routine finishes the cMouseBusy instance will be disposed of automatically, its Terminate event handler will be executed and the reference count will be reduced by one.

Because the program might have many forms open we must take account of the form when we set the busy icon because the MousePointer property belongs to a form not the application

So that we know which form's mouse pointer to change we must keep a separate count for each different client

Extend the code to allow for more than one type of busy icon. For instance an icon with a pointer that indicates that the user interface is still live and one without a pointer that indicates that the user must wait.

Objects of this class acquire the mouse busy status when created by a constructor called NewMouseBusy. They release it when they are terminated.

The busy status is simply a counter that is incremented each time a new cMouseBusy object is created and decremented when such an object is destroyed. If the counter increments to one then the mouse busy icon is set on the client object, when the counter decrements to zero the normal icon is set.

Remember that Visual Basic is single threaded and that the User Interface will not update until all code stops executing unless you call DoEvents so do this to make sure that the change to the mouse icon is visible.

DoEventsEndFunction

This function increments the count for the given object and returns the new count.

This function decrements the count and returns the new count. Note that if the count goes to zero then the entry is removed from the list; this must be done because the keys are objects and they will not terminate if we do not release the reference.