Loading and displaying a form from within another form’s code is fairly trivial. In some situations, this is all the interaction you need between forms. Each form is designed to operate independently of the others, but they can communicate via public variables (see the following section). In most situations, however, you need to control one form from within another’s code. Controlling the form means accessing its controls, and setting or reading values from within another form’s code.
In Chapter “Windows Controls in VB.NET“, you developed the Text Editor application, which is a basic text editor and consists of the main form and an auxiliary form for the Find & Replace operations. All other operations on the text are performed with menu commands on the main form.When the user wants to search for and/or replace a string, the program displays another form on which the user specifies the text to find, the type of search, and so on. When the user clicks one of the Find & Replace form’s buttons, the corresponding code must access the text on the main form of the application and search for a word or replace a string with another. The Find & Replace dialog box not only interacts with the TextBox control on the main form, it also remains visible at all times while it’s open, even if it doesn’t have the focus, because its TopMost property was set to True.
Sharing Variables between Forms
The preferred method for two forms to communicate with each other is via public variables. These variables are declared in the form’s declarations section, outside any procedure, with the keyword Public. If the following declarations appear in Form1, the variable NumPoints and the array DataValues can be accessed by any procedure in Form1, as well as from within the code of any form belonging to the same project:
Public NumPoints As Integer
Public DataValues(100) As DoubleCode language: VB.NET (vbnet)
To access a public variable declared in Form1 from within another form’s code, you must prefix the variable’s name by the name of the form, as in the following:
Form1.NumPoints = 99
Form1.DataValues(0) = 0.3395022Code language: VB.NET (vbnet)
You can use the same notation to access the controls on another form. If Form1 contains the TextBox1 control, you can use the following statement to read its text:
Form1.TextBox1.TextCode language: VB.NET (vbnet)
If a button on Form1 opens the auxiliary form Form2, you can set selected controls to specific values before showing the auxiliary form. The following statements should appear in a button’s or menu item’s Click event handler:
Form2.TextBox1.Text = "some text"
Form2.DateTimePicker1.Value = Today
Form2.Show()Code language: VB.NET (vbnet)
You can also create a variable to represent another form and access the auxiliary form through this variable. Let’s say you want to access the resources of Form2 from within the code of Form1. Declare the variable auxForm to represent Form2 and then access the resources of Form2 with the following statements:
Dim auxForm As Form2
auxForm.TextBox1.Text = "some text"
auxForm.DateTimePicker1.Value = Today
auxForm.ShowCode language: VB.NET (vbnet)
Multiple Instances of a Single Form
Note that the variable that represents an auxiliary form is declared without the New keyword. The auxForm variable represents an existing form. If we used the New keyword, we’d create a new instance of the corresponding form. This technique is used when we want to display multiple instances of the same form, as in an application that allows users to open multiple documents of the same type.
Let’s say you’re designing an image-processing application, or a simple text editor. Each new document should be opened in a separate window. Obviously, we can’t design many identical forms and use them as needed. The solution is to design a single form and create new instances of it every time the user opens an existing document or creates a new one. These instances are independent of one another and they may interact with the main form. Usually they don’t, because they aren’t auxiliary forms; they contain the necessary interface elements, such as menus, for processing the specific document type, and users can arrange them any way they like on the desktop.
The approach described here is reminiscent of Multiple Document Interface (MDI) applications. The MDI interface requires that all windows be contained within a parent window and, although once very popular, it’s going slowly out of style. The new interfaces open multiple independent windows on the desktop. Each window is an instance of a single form and it’s declared with the New keyword. I’ve used this style of interface to redesign the TextPad application of Chapter 6, and I’ve included the revised application in this chapter’s projects for your reference. Open the project in Visual Studio and examine its code, which contains a lot of comments.