VB .NET 2010 .Show()

[rex64]

In VB .NET 2010, one of my employees is trying to tell me that doing something like this is a bad idea:

frmQuickStart.Show()

And that instead we should create a global variable and only reference that?

Public QuickStart As frmQuickStart
QuickStart.Show()

I prefer the first method, and am curious if it is ok and safe to use?

[keystone_paul]

I'd take with a pinch of salt any advice telling you to create a global variable as generally they aren't necessary and violate Object Oriented design principles. Except where it becomes impractical you should try to keep the scope as local as possible and pass references to any areas of program that need it.

The reason your colleague is saying to use the 2nd method is because in the "old days" of VB when you created a form you only ever had one instance of that form and it was globally accessible throughout the program by the name of the form. Since VB edged towards object orientation things changed and effectively when you create a form in a project it is exactly the same as defining a class, so in theory you ought to create an instance of that form, which is exactly what the 2nd code snippet does.

You can still use the method you highlight in the first snippet, however I would suggest that the second approach is more in keeping with O-O design and you can potentially get tied in knots if you ever do create a new instance of the form.

[Shaggy Hiker]

I interpret this slightly differently than Keystone Paul, but I agree with everything he said. What I see as different is that from those snippets, you appear to be using the default instance, while your co-worker is using a non-default instance.

Default instances have been around since VB2005, and have been causing havoc all along. They were added to make .NET appear a bit more like VB6, where you never had to create an instance of a form to use it (though you could). A default instance is sort of like having this line:

Public frmViewAll As New frmViewAll

tucked away where you can't see it. It creates an instance of the form with the same name as the class name of the form. The default instances don't always behave the same way as non-default instances, though they are generally pretty close. The major problem with them is that people who are new to .NET or Object Oriented programming in general can be easily confused by them. This confusion can cause them to form incorrect mental models as to what a form is (it's just a class like any other class) and think of them as somehow special. They also often get to using the wrong instance because of a confusion about the default instance having the same name as the class type. Other than the confusion they create for no good reason, there is nothing particularly wrong with them.

I would prefer what Keystone Paul suggested, which is effectively: None of the Above. I would not create a global form variable unless I had a very specific reason to do so (and I have never had such a reason), and I would not use the default instance, which is what the first snippet appears to be doing.

[keystone_paul]

Apologies Shaggy Hiker - you explained more clearly what I was trying to say (I've been removed from programming for a while and terms like default instance had escaped my memory, and I'd forgotten that default instances were "reintroduced" after the initial version of .Net!)

[rex64]

I just edited the first form to have the same name to make it more clear what I am talking about.

Last edited by rex64; Today at 04:33 PM. Reason: Renamed first one to frmQuickStart to make it more clear.

I interpret this slightly differently than Keystone Paul, but I agree with everything he said. What I see as different is that from those snippets, you appear to be using the default instance, while your co-worker is using a non-default instance.

Default instances have been around since VB2005, and have been causing havoc all along. They were added to make .NET appear a bit more like VB6, where you never had to create an instance of a form to use it (though you could). A default instance is sort of like having this line:

Public frmViewAll As New frmViewAll

tucked away where you can't see it. It creates an instance of the form with the same name as the class name of the form. The default instances don't always behave the same way as non-default instances, though they are generally pretty close. The major problem with them is that people who are new to .NET or Object Oriented programming in general can be easily confused by them. This confusion can cause them to form incorrect mental models as to what a form is (it's just a class like any other class) and think of them as somehow special. They also often get to using the wrong instance because of a confusion about the default instance having the same name as the class type. Other than the confusion they create for no good reason, there is nothing particularly wrong with them.

I would prefer what Keystone Paul suggested, which is effectively: None of the Above. I would not create a global form variable unless I had a very specific reason to do so (and I have never had such a reason), and I would not use the default instance, which is what the first snippet appears to be doing.

[rex64]

Thanks. I will avoid using the global variables. I will instead use the first method: just use the name of the form and .SHOW().

... I would not create a global form variable unless I had a very specific reason to do so (and I have never had such a reason), and I would not use the default instance, which is what the first snippet appears to be doing.

[Shaggy Hiker]

But that is making use of the Default Instance, which I would consider to be the greater evil, frankly.

I guess I should add that the way I would do it would be to create a new instance (not using the default) much like the second snippet you posted, but I would create it only where it was needed. That means that I have a fair amount of code that looks like this:

Dim nf As New SomeForm

nf.Show

That would be found inside a method. Occasionally I have the declaration of the form outside of a method, in which case I use a better name than 'nf', but it would be Private, rather than Public.

@Keystone Paul: I thought your answer was a good one, I was making a longer rant about default instances specifically.

[Sitten Spynne]

*edit* I, too share Shaggy Hiker's dislike of default instances. I think I hate them more because I used more words!

I don't really have enough information to answer the question, but I'm going to lean towards what your employee is saying due to some old scars. There are very few scenarios where doing something is *always* a bad idea. Here's some angles.

I'm assuming in the first technique your forms class is named "frmViewAll". If this is the case, then you are using a feature of VB called the "default instance" and I would advise extreme caution. It works great in small applications, particularly when you only need one instance of any form ever.

Default instances declare a global property that more or less looks like this:

Private _frmViewAllInstance As frmViewAllInstance

Public Shared ReadOnly Property frmViewAll
    Get
        If _frmViewAllInstance Is Nothing OrElse _frmViewAllInstance.IsDisposed Then
            _frmViewAllInstance = New frmViewAll()
        End If

        Return _frmViewAllInstance
    End Get
End Property

Nothing magic, just a typical "lazy instantiation" pattern and simple pseuo-Singleton.

This can cause you grief later if you don't know what you're doing. I can't count how many times someone's told me VB is broken because their code doesn't work:

' Local variable hides the default instance...
Dim frmViewAll As New frmViewAll()
frmViewAll.Show()

' Then, in some other Sub/Function
' This touches the default instance, not the local variable from before!
frmViewAll.Close()

If you use the default instance, you have to use it *everywhere*. There is nothing that connects an instance you create manually (like myform in the last snippet) to the one that the default instance manages. On large multiform projects, default instances tend to introduce more troubles than they are worth.

When I write large applications and need several of my forms to be able to communicate with each other, I make a class that ties them all together. Here's an example of what the API for such a class might look like:

Public Class TwitterClientForms
    Public ReadOnly Property TimelineForm As TimelineForm
    Public ReadOnly Property OptionsDialog As OptionsDialog
    Public ReadOnly Property ListForms() As ListForm

    Public Sub AddListForm(some parameters)
    
    Public Event ListFormClosed ...
End Class

You could argue that it's more work to have an entity that manages these forms. This is true. First, note it's a technique for applications with many forms and complex interactions between them; I use simpler techniques for smaller applications. This is work that gives you the ability to control how the forms are managed. For example, the default instance can only keep track of one form; this implementation tracks many. The default instance can't handle forms that might need complex configuration before display; this lets me build that information in.

Analogy time! Default instances are a hammer. Hammers are great at fastening wood together with nails. When you hit a situation that requires a screw, hammers aren't quite as useful. Alternatively, if you need to put shingles on a roof that can involve hundreds of nails; a hammer gets tiresome. A good carpenter would recognize these scenarios as the appropriate time to visit his toolbox and choose a new tool. So, too, must programmers switch between various tools to match the problem.

Personally I find that my projects almost always outgrow default instances and, as such, I never use them. I see no point in using a feature that I will almost always have to backtrack and replace; I'd rather choose something that works in all cases.

[keystone_paul]

Agree with pretty much all of whats said above.

I mention my history because in the days (up to VB5?) default instances were the way of doing things, and so if the OP goes back to those days like I do and havent been actively looking at the changes in the intervening years, they will probably be more familiar with the approach in snippet #1

I never use default instances these days but it took a bit of work to get used to not doing it after many years when it was the way of doing it!

[Shaggy Hiker]

Heck, back when I was working in VB5/6 I couldn't even see the point in using anything other than the default instances for most tasks. In .NET I never use them.

[rex64]

Ok, I see what you mean. It seems like option 2 would be best. In my project I NEVER want a form to be displayed more than once.

[jmcilhinney]

Default instances are basically a way to help beginners who don't understand OOP principles and can't get their head around the fact that the form that they design is a type and not an object. It also helps beginners access one form from another without having to pass references around. If you understand how to do both those things then there's never a need to use default instances.

Default instances have caused as many problems as they've solved and I (along with Shaggy and others) don't like them for that reason. That said, the problems they have caused are with the same beginners that they were intended to help. If you understand default instances then you won't fall into those traps, e.g. using a default instance on a secondary thread or creating an explicit instance and then trying to access it via the default instance. As such, using default instances is not a problem.

While it's not a problem, it's also not really a benefit. Anything you can do with default instances, you can do with instances that you create explicitly. In most cases where they might help, it's actually more OOPish to not use them. The one case where they might be beneficial is when you explicitly want to prevent more than one instance of a form being shown. Default instances act somewhat like a singleton, so they you can write a few less lines of code in that case. Those lines are simple though.

My last point is that, if you are using the Application Framework in VB then you can't avoid default instances altogether because the startup form is the default instance of its type. Other than that though, I never use them and I never miss them. They are not inherently bad but their benefit is dubious. Either way though, you should be consisitent. If you use default instances at all (other than the startup form) then use them all the time except in those situations where you specifically need multiple instances of the same form.

[rex64]

Thanks everyone. My last question, is there a way to turn of the ability to use the default instances? A way to remind me to use the correct instance?

[jmcilhinney]

No there isn't, unless turning off the Application Framework does it, which I haven't tested but I doubt. If you just think of forms as you do any other objects then you will treat them as you do any other objects, which means using a constructor to create an instance. I don't really think you should need a reminder for that.

[rex64]

Ok, thanks!