Modeless UserformsMost of the dialogs that we normally come into contact with are modal, which is to say that neither the application nor the user can do anything until the form is dismissed. When the Show statement is processed, by default the application window is disabled (so none of the menus are available), the form is displayed and the code stops. Snippets of code can run in response to control events, but it's not until the user closes the form that execution continues on the line after the Show statement.When a userform is shown modeless, however, code execution continues immediately after the Userform_Initialize and Userform_Activate event procedures have finished, with the userform remaining displayed. If the code comes to an end while a modeless userform is displayed, the form remains open and both the userform and the application window can be used.NOTEExcel 97 does not support modeless userforms. Splash ScreensThe simplest use for a modeless userform is as an introductory splash screen. The userform is shown modeless at the start of the Auto_Open or Workbook_Open procedure and unloaded at the end of the procedure. Listing 10-23 shows a simple example, where the form uses the SetUserformAppearance procedure from earlier to remove the title bar. Listing 10-23. Showing a Splash Screen at Startup
Progress BarsA rather more interesting use of modeless forms is to display progress information to the user during lengthy looping operations. Figure 10-11 shows a simple progress bar userform, where the progress indicator is made up of two overlapping Frame controls, each containing a label. The back frame has a white background and a label with blue text, and the front frame has a blue background and a label with white text. As the progress is updated, the width of the front frame is adjusted, allowing us to see more of the blue background. This makes the bar appear to fill up as the progress increases. Figure 10-11. A Modeless Progress Bar![]() Listing 10-24. Using the Progress Bar Userform
Combining with Menu ItemsIf we display a modeless userform and then allow our code to finish, the form is left active on the screen, and both the form and the application can be used. This behavior can be used to very good effect in form-based dictator applications. In this design, the worksheet is only ever used for a backdrop graphic display; all the interaction with the user is done through userforms. Most form-based applications have a central "switchboard" form, with a set of buttons to show subforms for each functional area. Those forms have their own buttons to show other forms and so on. It is usually very difficult to navigate around the application. If we use modeless userforms, however, the menus are available, so we can implement a menu structure that enables the user to quickly switch between parts of the application.To implement this design, we need to be able to communicate with all the forms, so they can be notified when the user clicks a menu item to jump to another form, or when the application is about to exit, or if the Save menu item is clicked. All the forms will have to include the same set of standard functions, shown in Listing 10-25, that can be called from a central "form-handler" routine. Listing 10-25. Standard Routines to Be Included in All Modeless FormsWith all the userforms having the same set of standard routines, we can write a simple centralized routine to manage them all, shown in Listing 10-26. Listing 10-26. The Central Control Routine to Handle Navigation Between FormsUsing this mechanism, we can add more userforms to the application without having to add any extra code to control their display; as long as they include the standard set of procedures shown in ![]() |