Code Focused

Magic Forms Access in Visual Basic and C#

Look behind the curtain on this one, and you'll see that code is quite magical in and of itself.

• By Tim Patrick
• 10/27/2016

Accessing a specific form within a Visual Basic Windows Forms application is magical. Simply naming the form in any part of your source code causes that form to--presto--magically pop into existence:

Form2.ShowDialog()
' ----- And there it is!

Behind the scenes, Visual Basic is treating the form mention as a shortcut to the My.Forms pseudo-collection:

My.Forms.Form2.ShowDialog()

This is a little more informative, but you still can't tell what's really going on, because it's magic. If you could peer inside the My.Forms feature, you might find Visual Basic adding parallel form access points for every Form-derived class you include in your application, as shown in Listing 1.

Partial Friend Module My.Forms
  ' ----- Internal, hidden storage for the magic form.
  Private InternalForm2 As WindowsApplication1.Form2 = Nothing

  ' ----- The public face of the magic form.
  Public Property Form2 As WindowsApplication1.Form2
    Get
      ' ----- Ensure a form always appears when requested.
      If (InternalForm2 Is Nothing) Then _
        InternalForm2 = New WindowsApplication1.Form2
      Return InternalForm2
    End Get
    Set(value As WindowsApplication1.Form2)
      ' ----- Allow clearing, but not overwriting, of form.
      If (value Is Nothing) Then
        InternalForm2 = Nothing
      Else
        Throw New Exception("That's a no-no.")
      End If
    End Set
  End Property
End Module

So, it's not magic, it's just code. Which means it's just like C#, because -- and learning this is part of growing up and becoming an adult -- the C# language has no magic. It also means you can do the same kind of form-magic thing in C#, if you add similar code, as shown in Listing 2.

static internal partial class MyForms
{
  // ----- Internal, hidden storage for the magic form.
  private static WindowsFormsApplication1.Form2 InternalForm2 = null;

  public static WindowsFormsApplication1.Form2 Form2
  {
    get
    {
      // ----- Ensure a form always appears when requested.
      if (InternalForm2 == null)
        InternalForm2 = new WindowsFormsApplication1.Form2();
      return InternalForm2;
    }
    set
    {
      // ----- Allow clearing, but not overwriting, of form.
      if (value == null)
        InternalForm2 = null;
      else
        throw new Exception("That's a no-no.");
    }
  }
}

Now you can do the magic in C#:

MyForms.Form2.ShowDialog();

A big downside to this code is that you must add it for every form included in your project. You could inject yourself into the Roslyn code generation process and emit the necessary partial MyForms class elements on a per-Form basis. Another option would be to use Reflection to scan through your assembly at runtime, looking for valid forms, and providing access to each one through an indexer or similar construct. But those sound like a lot of work. Don't those sound like a lot of work to you?

Of course, all of this begs the question as to whether this is the best way of invoking forms in a Windows Forms application. The traditional way of creating forms in C#, via as-needed instantiation, is probably the best way to manage form lifetimes in both C# and Visual Basic:

// ----- The best C# way...
(new WindowsFormsApplication1.Form2()).ShowDialog();

' ----- And its Visual Basic equivalent...
Call (New WindowsApplication1.Form2).ShowDialog()

But that's just code, not magic. And every program needs a little magic now and then.