The Start-Up form . VB Help

A typical application has more than a single Form. When an application starts, the main Form is loaded. You can control which Form is initially loaded by setting the start-up object in the Project Properties window,To open this dialog box, choose Project> Project Properties.


By default, Visual Basic suggests the name of the first Form it created when the project started, which is Form!. If you change the name of the Form, Visual Basic won’t use the new name. Instead, when you try to start the application, Visual Basic will display an error message indicating that you must.specify the start-up object, and then it will display the Project Properties window . .You can also start an application with a subroutine without loading a Form. This subroutine must be called Main and it’must be insertedin a Module. If you specify the Main subroutine as the Start-up Object in the Project Properties window of 19ure 4.2, you must load and display the application’s Forms from within the Main subroutine with the statements described in the next section.

Loading, Showing~ and Hiding Forms

Before we look at the methods and statements for displaying Forms, let’s look at the three possible states of a Form:

• Not loaded The Form lives on a disk file and doesn’t take up any resources
• Loaded but not shown ·The Form is-leaded into memory, takes up the required resources, and is ready to be displayed.
• Loaded and shown The Form is shown, and the user can interact with it.

Loading and Unloading Forms

To load and Unload Forms, use the Load and Unload statements. The Load statement has the following syntax:

Load formName and the Unload statement has”this syntax:

Unload form Name

The formName variable is the name of the Form to be loaded or unloaded. Unlike the Show method, which takes care of both loading and displaying the Form, the Load statement doesn’t show the Form. You have to call the Form’s Show method to display it on the Desktop.
Once a Form is loaded, it takes over the required resources; so you should always unload a Form that’s no longer needed. When a Form is unloaded, the resources it occupies are returned to the system and can be used by other Forms and/ or applications. Because loading a Form isn’t instantaneous, especially if the Form contains bitmaps or other resources that entail loading large files, don’t unload a Form frequently in the course of an application. If your ‘application contains many Forms, balance the benefit of.having them all in memory versus loading certain furthers as needed. Opening a database ‘and setting up the related Structures {we’ll look at them in Chapter 17, Database Programming with Visual Basic), for instance, doesn’t take place instantly, and your application shouldn’t load and unload Forms that
access databases. It’s best to keep the Form loaded in memory and display it when the user needs it. .

‘Showing Forms

To show a Form, you use the Show method . If the Form is loaded but invisible, the Show method brings the specified form on top of every other window on the Desktop. If the Form isn’t loaded, the.Show method loads it and then displays it. The Show method has the following tax  formName.Show mode TheformName variable is the Form’s name, and the optional argument mode determines whether the Form will be modal or modeless.Jt can have one of the following values:

• O-Modeless (default)
•  I-Modal

Modeless Forms are the norm. They interact with the user, and they allow the user to switch to any other Form of the application. If you don’t specify the optional mode argument, the Show method displays the Form as.modeless. A modal Form takes total control of the application and won’t let the applications proceed unless the Form is closed. A modal Form, therefore, must have a Close button or some means for the user to close it so that they can return to the
Form from which the modal Form. was loaded. The InputBox O function, for example, displays a Modal window. Unless the user clicks on the OK or Cancel . button, the program can’t continue. When an InputBox is displayed, you can’t even switch back to the program’s Main window.

The Show method will also load the Furtn if necessary. You might wonder why you would load and then show a Form if the Show method takes care of both steps. There are two reasons for loading Forms separately:
1. Some Forms don’t need to be displayed; they only need to be loaded. These Forms may contain procedures needed by other applica dons or have a special function, such as doing something in the background. For example, a Founed with a Tuner control that tracks time or other events doesn’t need to have a visible user interface.
2. You can speed up the display of a Form by loading it of time. Loading a Form takes time, especially if the Form contains large bitmaps or many controis. The delay associated with loading a Fonn can be avoided if the Form is loaded on start-up. The loading time won’t be reduced by loading a Form at start-up, but after the application is loaded and rUnning, there won’t be any substantial delays. The Forms will be in memory, and the Show method can display them instantly.

Hiding Forms

If your application ‘uses many Forms, you may want to hide some of them to make room on the Desktop for others. To hide a Form, use the Form-s Hide: method, whose syntax is:


To hide a Form from within its own code, use the statement:


Forms that are hidden are not unloaded; they remain in memory and can be displayed instantly with the Show method. Forms that may be opened frequently, such as a Search & Replace window, should be hidden when they are not needed. The next time the User opens the same window there will be no noticeable delay. Forms that aren’t opened ‘frequently in the course of an application, such as a Preferences or Options window, should be unloaded to reclaim the resources. When a Form is hidden, you can still access its properties and code. For example, you can change the settings of its Control properties or call any Public functions in the Form, even its event handlers (as long as you make them public by changing the default ”Private” declaration of the corresponding event handler to “Public”). The topic of manipulating a Form’s controls from within another Form’s code is discussed later in this chapter in the section “Controlling One Form from within.Another.” If you plan to manipulate the controls on a Form at ru ntime, you can do so while the FOQI\is loaded but not visible (see also the section “Building Dynamic Forms at Runtime,” later in this chapter). After you have manipulated the controls on the Form, you can display it with the Show method .

Posted on November 4, 2015 in Working with Forms

Share the Story

Back to Top
Share This