Home > General, Technology > Why Default Form Instances need to die

Why Default Form Instances need to die

And I’d like to see them die a quick and painless death too. Just rip it out, like a band-aid, the quicker the better.

I came across a thread today where the poster was wanting to know why code they had used worked on one form, while the seemingly same code was not working on another form. (I’ll spare the poster the embarrassment of linking to the post directly. At least it’s not their fault… but I’ll get to that eventually.)

Here’s the “working” code in question (from the load event of Form2):

Me.Text = form1.textbox1.text

The intent of the code is straight forward and simple: Make the title of the current form the value that is found in Textbox1 on Form1. This is actually quite a simple and common request. Something on the current form is dependent upon something in a different form.

Now here’s the code in question that doesn’t work (from the Load event of Form3):

me.text = Form2.textbox1.text

Look familiar? It should. It is “exactly” like the previous code snip, right? But according to the poster “it doesn’t work.” The poster then goes on to note that there are no error messages or anything else, it simply isn’t setting the caption of the form to the value “found” on form2. This is one of the pitfalls of default form instances and is what trips up most people.

At this point in the thread, what isn’t known is how form2 is being shown. What is suspected is that the poster has done something like this:

Dim someForm As New Form2
someForm.Show 'This causes the form to load and run the code in the Load event

What we end up with in this case is an instance of Form2 is being created and shown. And this is a good practice. But it is not the default instance. So if the same code is then used to show form3, when it loads, it attempts to get the data from instance Form2. But the instance that was created and is being displayed is someForm. So when Form3 (or any instance of it) loads, it tries to get its data from the defauit instance of Form2 which doesn’t have the data.

So, you maybe wondering how come it worked when Form2 was loaded? Shouldn’t have form2 come out blank since it was accessing Form1, which is also the Default Instance as well? Yes and no.

Yes, in theory it shouldn’t work either, but presuming that Form1 is the default start up form for the project/application, the default instance of the form is what is being used. This is why when the Load event for Form2 fires off, it was able to get the data from Form1, because in this case, Form1 really did exist.

Great, so what we do about it? Until Microsoft comes back to their senses, we are stuck with it and its repercussions. Default forms was originally removed from VB with the original Frameworks (1.0/1.1 – VB2002/VB2003) but was then added back in starting with Framework 2.0 (VB2005). I’ve been lamenting that move ever since. In my opinion it was a step backwards in the evolution of VB (one of several… topic for another time). In the meantime, be aware of default forms, avoid using them if you can. Now, I will admit, there MAY be some cases where using them makes sense, and should be used with extreme caution, both eyes open and full awareness of what the impact is going to be.

This does expose another issue, however. If you have a FormB that needs data from FormA, but you aren’t using default form instances, how does FormB know about the FormA instance to get the information? In short, it doesn’t. It never should. It should never care that it’s caption came from FormA, FormZ , Form007 or Form99. the best way to solve this kind of problem is through parametrized constructors.

Example of a parametrized constructor:

    Public Sub New(ByVal NewCaption As String)

        ' This call is required by the Windows Form Designer.

        ' Add any initialization after the InitializeComponent() call.
        Me.Text = NewCaption

    End Sub

This takes a single parameter and uses that value to set the caption of the form.

Dim newForm As Form1 = New Form1("A New Form Caption")

As you can see, now when we create the instance of the new form, we pass it the info it needs. It no longer is dependent upon any other form. And now we can re-arrange the forms. So instead of FormA calling FormB and formB calling FormC…. we cna have FormA call FormC and FormC cna call FormB. And the forms are none the wiser.

All too often I see people getting hung up because they’ve unknowingly mixed instanced forms with the default ones. I think this is a concept whose time has long since come and gone and it’s time to give up the crutch. Problem is that because this is something that is baked into the language itself (it’s not part of the Framework, but the VB language itself) it’s easier to get things in than it is to get things out. So we’re stuck with it for better or for worse.

Categories: General, Technology
  1. No comments yet.
  1. No trackbacks yet.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: