The Windows Form is a special object in VB.NET. For desktop applications, it's the module that's called to start the application. I wrote an article in 2011 about some of the ... well ... "uniqueness" of Windows Forms in the article, Multiple Form Instantiation in VB.NET. In that article, I explain some of the strange things that can happen when you explicitly instantiate a Form object ...
Dim theForm as New Form theForm.Text = "Whatever"
... versus simply referencing the new Form object after it's added.
theForm.Text = "Whatever"
In the second case, a Form named "theForm" has to be added to the project. In the first case, it's possible to add a Form to a project without adding it through Visual Studio. For example, these two lines of code will display a Form (with no title):
Dim theForm As New Form theForm.Show()
But then you miss the "secret sauce" code in the theForm.Designer.vb file because no file is created. (You have to click "Show All Files" to see these files.) and there's no support in Visual Studio. (No "Properties"; no "Solution Explorer" for theForm.) This is not a recommended technique.
If you add the form through Visual Studio, you can still explicitly instantiate it. It's still not clear to me whether that's necessary or not. That's a big part of the article I referenced above. And you don't have to use the name you used to add it to the project. In other words, you can add a form named "theForm" to a project and then instantiate it this way:
Dim aDifferentFormName As New theForm aDifferentFormName.Show()
At least one C# programmer (where they do it differently) has written that this leads to naming problems:
"This class versus instance problem leads to the sort of naming problems typified by CStack ..."
Not so. VB.NET programmers nearly always use identically the same name. In fact, this article is the only time I can remember when I haven't.
This, however, does lead to another question. For any other class, if you simply used it in code without instantiating it, the elements in it have to be treated used as Static. In code, suppose you added a class named "theClass" to a project. Properties and methods in that class have to be declared as Shared before they can be referenced in another class if the class isn't instantiated.
Public Class theClass Public Shared Property theProperty As String Public Shared Sub theMethod() Console.WriteLine("Whatever") End Sub End Class ' ... in some other class ... theClass.theProperty = "Whatever" theClass.theMethod()
Does this mean that elements in the Form are shared too? In specific fact, "No." There is a kind of hidden "auto-instantiation" happening. You can actually prove this to yourself by modifying the designer code created by Visual Studio to add a constructor. (The New subroutine.) Show All Files and then open the designer code window for a form that you have added to the project. Ignore the scary warning ...
'NOTE: The following procedure is required by the Windows Form Designer 'It can be modified using the Windows Form Designer. 'Do not modify it using the code editor.
... and add a New method right below it.
Sub New() Console.WriteLine("theForm New Called") End Sub
Another scary warning message is displayed for the New method telling you that you should be using the InitializeComponent method. Ignore this one too. We're just testing.
Now, when you simply use the form in code without instantiating it ...
theForm.Text = "Whatever"
... the Output window confirms that the New method has been called.
These are the kinds of confusing inconsistencies that caused Microsoft to add the My object to VB.NET in VB.NET 2005. Occasionally, my blog at About Visual Basic is worth linking just to read the excellent comments contributed by readers and this is one of those cases. To fully appreciate this article and learn even more, try this blast from the past. To Instantiate or Not To Instantiate?
And be sure to try John McIlhinney's column which is also linked in the comments!