In traditional programming, one technique to make certain that a newly written program is behaving properly is to insert a couple of diagnostic "print statements", and then to verify that all information printed through these statements corresponds indeed to the expected behavior. While working in a windows-based environment, this technique can not quite be followed, because the flow of commands is now event-driven, and no longer in any sequence that can be anticipated by the programmer. A new feature that can be used to replace the old "diagnostic print statements" is the "pop up window". The utility program ^%msgbox can be called in a number of fashions to produce different kinds of information displays.
The following addition to the create logic for the text box shows how this feature might be used.
(In this case, a new method is used to define the "action logic" code: right click on the component in question to pop up a menu; one of the choices in this menu is "New Event". Clicking on this option displays the list of possible events for which "action logic" code may be entered.)
(Click here to cut and paste this code.)
Now, when the window is re-tested, a window will pop up presenting this message.
The text "WS11" in the header-bar can be customized by providing an additional parameter to the subroutine in ^%msgbox.
(Click here to cut and paste this code.)
Such pop-up windows with diagnostic messages can be extremely helpful while testing software. However, there are situations where such pop-up windows should not be used. In the next step, a feature will be added to the "gotFocus" action logic of the Drop Down List. If a pop-up window would be produced in the course of processing of this event, the pop-up window would receive focus when it is presented. Next, when the end-user closes the pop-up window, focus returns to the Drop Down List, causing another "gotFocus" event to happen, and another pop-up window to be displayed. In short, this would create an infinite loop of events. In such a case, the software would never "return" often enough to actually process the original event that started the chain.
Hint: while the pop-up window is displayed, it will not be
possible to set focus to its parent window. In other words, the
pop-up window must be closed before the window from which it was
created can be re-activated. This feature is called "modality". A
"modal" window is a window that "insists on being processed
completely" before control can be returned to its parent
window.
In some cases this is an extremely valuable and desirable
feature, in some other cases, this feature has no merit at all.
The needs of the software at hand will decide which
is the case.
Go on to the next page in this sequence.