In modal programming, which is the standard method of programming taught in most colleges, universities, and on-the-job training programs right now, things always happen in a logical, predefined sequence. You can draw a flow chart for a modal application; you can draw process diagrams; you can use a variety of different methods to portray visually what will happen at a particular point in your program. In any of your functions, you know (or can determine) what path the user took to get to this function; you know what he did immediately prior to this, and what he will be doing afterward. In the example we were using above, with two data forms and an event function that called the second form, you know that if the user is in the first form, he has either completed the second form or has not entered any information in it. Your functions do not have to deal with the possibility that the second form has only been partially filled out, and may contain incomplete information.
In a non-modal application, you have no such certainty. Things happen as the user dictates, and you, the programmer, have no control over them. It is extremely difficult to diagram a true non-modal program using something like a flow chart or a process diagram, because, no matter what activity the user is currently doing, he can always switch to another activity before completing the current one. In fact, if the program is not carefully designed, he can exit the entire program before completing any particular activity.
This has several implications for your Vermont Views application. First, user functions associated with a non-modal form, and event functions in a non-modal application, cannot rely on information in other non-modal forms. The user may have chosen to switch tasks before completing those other forms. If the other forms are in memory (which is not guaranteed), they may contain no information or only partial information.
Second, user functions that process non-modal objects cannot make assumptions about whether that non-modal object is on the screen, or whether it is in memory. They must check. If the object is not in memory, the user function must allocate it; if the object is not on the screen, the user function must put it there. For example, if you write a user function that allows the user to browse through information contained in a window, your user function should not blindly call wn_def() or dl_wnget() to allocate the window. It should first check whether the window already exists; otherwise, you may end up with several copies of the window in memory, which may eventually cause your program to run out of memory and crash. If the window already exists, your user function still cannot assume that the window is currently on the screen; it must check, and if the window is not on the screen, put it up. If you fail to check, you may accidentally set the window on the screen several times (and then wonder why it doesn't disappear when you take one copy off the screen!)
