You couldn't do My.Forms instantiation in VB until .NET 2005 when the My objects were added to the language. As Microsoft puts it:
"... the My.Forms object creates a new instance of the form when it is accessed and stores it. Subsequent attempts to access that property return that instance of the form."
In effect, VB.NET does almost the same thing that C# does, but C# makes you write the code yourself.
My.Forms instantiation and explicit instantiation are not exactly the same. For example, suppose we use exactly the same code shown earlier in a button click event so we can repeat it. (Remember: OriginalForm has to be added to the project in Visual Studio.)
Public InstantiatedCopy As New OriginalForm
Private Sub changeTitleAndShow_Click(
ByVal sender As System.Object,
ByVal e As System.EventArgs
) Handles changeTitleAndShow.Click
OriginalForm.Show()
InstantiatedCopy.Text = "Instantiated Copy"
InstantiatedCopy.Show()
End Sub
Then add a second button to close both:
Private Sub CloseForms_Click(
ByVal sender As System.Object,
ByVal e As System.EventArgs
) Handles CloseForms.Click
OriginalForm.Close()
InstantiatedCopy.Close()
End Sub
Click the first button and both forms open. Click the second and both forms close. Click the first again and the app crashes with an interesting error:
Cannot access a disposed object. Object name: 'OriginalForm'.
Although the message references OriginalForm, the explicitly instantiated form is actually the one that is crashing when the code tries execute the Show method.
In other words, the traditional, often recommended "explicit instantiation" approach crashes but the new My.Forms instantiation works fine. When an explicitly instantiated form is closed, VB disposes it and it's not available anymore. But since the form you added to the project is still there as a file, the compiler just instantiates it again.
--------
Click Here to display the illustration
--------
Although closing a form disposes it in the sense that you can't execute the Show method, you can explicitly dispose a form by setting it to Nothing. Repeating the example above with both forms set to Nothing instead of closing them gives you a different error.
--------
Click Here to display the illustration
--------
Sharp eyes will note that the My.Forms instantiated form also closes when it's set to Nothing, but the explicitly instantiated form does not. It's still there on the screen, but you can't do anything with it - a situation that could cause a lot of confusion for your users. In particular, when you try to change the Title (the Text property), you get the NullReferenceException shown above. But the My.Forms instantiated form continues to work just fine.
This appears to be such a significant change in behavior that I can't understand why Microsoft hasn't documented it more fully. But my conclusion is that, at least in VB.NET, the traditional recommendation to use explicit instantiation isn't such a great idea.
---------------------------
Note: When I did the research for this article, I decided to pose the question on Microsoft's VB.NET language forum. A whole group of programmers assured me that failing to explicitly instantiate the form was bad, evil, and no one would to sit at the same table with me in the company cafeteria.

