When you show a form, Visual Basic lets you specify whether you want to show it modally or nonmodally, using the constants vbModal and vbModeless. This isn't a very flexible way of implementing modes, however; a vbModal form is task-modal, which means it locks out all user input from the rest of the application. This type of modality is really suitable only for pop-up dialog boxes. When you specify vbModal when you show a form, the only way you can show two forms together is if they have a parent-child relationship. This restriction imposes a particular set of design restrictions on your application, and it might prevent you from doing what you want. It's also impossible to display a nonmodal form from a modal form, another potentially intolerable situation.
Consider the example shown in Figure 13-1, which is a non-MDI application with several distinct functions invoked from a main menu. Perhaps it's a database maintenance program, and you would like to be able to refer to display functions while using update functions. In Figure 13-1, I've shown two functions executing at the same time; forms A and C can be considered parent forms for Function 1 and Function 2, respectively. Parent form A is also displaying a child form, form B.
Although the forms shown in Figure 13-1 are relatively simple, it's likely that you'll want form A to display form B modally, or more specifically, for form A to be inaccessible for as long as form B is on the screen. The conventional way to code this is for form A to call FormB.Show vbModal, but this locks all user input from any form except form B-including the main menu. Hence, it wouldn't be possible to reach the situation shown in Figure 13-1. The alternative, FormB.Show vbModeless, doesn't prevent you from accessing multiple functions at the same time, but it interferes with the design of each function and greatly increases the complexity of the program. Clearly, you need to find something in between.
Figure 13-1 An example of function modality: form A is not accessible here
Visual Basic's built-in support for modal forms is geared toward simple pop-up dialog boxes, but that doesn't stop you from building modes by other means. Forms have an Enabled property that, when set to False, effectively mimics what happens to a parent form when it shows a vbModal child. Now that you're in control, however, you're free to enable and disable forms at will, without the restrictions imposed by vbModal.
Returning to the example in Figure 13-1, all you need to do is to create form B as modeless, then disable form A when form B loads and reenable it when form B unloads (or possibly on Show and Hide instead of Load and Unload). This implements a new kind of mode that's more appropriate to your requirements; you might call it "function modality," since you're creating an architecture in which it's permissible to hop back and forth between functions yet each function is effectively a modal cascade of forms. This architecture is only one possibility; a less orthodox architecture is shown in Figure 13-2.
Figure 13-2 The Create New Publication and Review Publication forms swap with each other
Figure 13-2 shows a database application that's used to keep records of technical publications. Users can choose an existing entry from the list and edit it using the Review Publication form, or they can enter a new publication by calling Create New Publication. Notice that the Create New Publication window has a Review button, and the Review Publication window has a New button. This arrangement could imply multiple instances of each screen, but let's say that the design calls for screens to be swapped when these buttons are used. For example, the user could call up the Create New Publication window to enter the details for a new publication and then press the Review button to move immediately to the Review Publication window to enter a review of it. As the Review Publication window loads, it replaces the Create New Publication window, which is unloaded. The Select Publication window is disabled when either the Review Publication window or the Create New Publication window is displayed.
There is no elegant way to implement this architecture using Visual Basic's standard modality features. You would somehow have to defer your request for the review form to be displayed until the Create New Publication form was unloaded. You could make it work, but it would be tricky and it would be ugly. You'd be much better off devising a general mechanism to support the kinds of modes you want to enforce.
