Building Windows Applications

Programming Without Default Form Instances

Classes and objects existed in Visual Basic 6.0, but they were not as pervasive as they are in .NET. Objects are everywhere when you are developing in Visual Basic .NET, and that large change has lead to many small changes that can trip you up when you are coming from a VB6 background. One of the more commonly encountered problems for a VB6 developer is the lack of default form instances in .NET, but the term default form instance is confusing enough that I will need to go into more detail about the problem before we look at any solutions.

When you are dealing with classes and objects, it is helpful to think of a class as the blueprint of a house, whereas an object is an instance of a specific class and is more like an actual house that was built from the blueprint. In general, you don't work with classes, just like you don't live in blueprints. You create instances from your classes and it is those instances that get used throughout your applications. This is not a .NET issue; this is just how classes and objects work, even in VB6. Even in VB6, forms are considered classes, which is why you can create multiple copies (instances) of a single form in your VB6 code if you wish. The two snippets of code in Listings 3.17 and 3.18, assuming you have a Form1 in your project, would produce the same result (11 open copies of Form1 ) in VB6 or VB .NET. The only differences between these two examples are syntax issues; they are otherwise identical.

Listing 3.17 VB6 Code to Display 11 Copies of a Form

'VB 6 Code
Dim i As Integer
Dim myFrm As Form1
For i = 0 To 10
  Set myFrm = New Form1
  myFrm.Show
Next

Listing 3.18 The Very Similar VB .NET Code for Displaying 11 Copies of a Form

'VB .NET Code
Dim i As Integer
Dim myFrm As Form1
For i = 0 To 10
  myFrm = New Form1()
  myFrm.Show()
Next

In each case, the code examples created 11 new instances of the class Form1 and then called a method ( Show ) on each of those new instances. Code you wrote in VB6 that worked with multiple instances of a single Form class will probably work in .NET without too many changes, but consider this VB6 code:

Form2.Show
Form2.TextBox1.Text = "dfsdf"

That code would not work in .NET, because it is treating the class Form2 as if it were an instance of Form2 . In Visual Basic 6.0 and earlier versions, a special default instance of each form is automatically created, and allows you to use the form's name to access this instance. What this means is that the Visual Basic 6.0 code Form2.Show has the effect of showing the "default" instance of Form2 , but it doesn't work in Visual Basic .NET. If you want to show a form in VB .NET, you need to create an instance, writing code like this to make Form2 visible:

Dim myFrm As New Form2()
myFrm.Show()

This is a major behavioral change from VB6, but the difference in code is not extreme. The removal of default instances changes more than just the code to show a form though. The second part of the problem is that these special default form instances were global to your entire project in Visual Basic 6.0. Taking the two facts together means that (in Visual Basic 6.0 or earlier) you can refer to any form in your project from anywhere in your code and you will always be referring to the same instance of that form.

In Visual Basic .NET, if you need to access an instance of Form2 from some other part of your application (such as another form or a module), you need to pass the reference to Form2 around your application. The next section explores some of the ways in which you can work with multiple forms.

You might also like...

Comments

Contribute

Why not write for us? Or you could submit an event or a user group in your area. Alternatively just tell us what you think!

Our tools

We've got automatic conversion tools to convert C# to VB.NET, VB.NET to C#. Also you can compress javascript and compress css and generate sql connection strings.

“If debugging is the process of removing software bugs, then programming must be the process of putting them in.” - Edsger Dijkstra