Visual Studio.NET allows you to set a property that makes your application a single-instance application, where double-clicking the icon while the app is running simply brings the already-running app to the foreground.  But what if you wanted the option of having multiple instances, say for power users?  Well, you could start by creating an application setting, so you have My.Settings.AllowMultipleInstances to work with.  But now where do you set it? 

Visual Studio allows you to patch in to application events.  Click the View Application Events button in the application properties page and a new file is created: ApplicationEvents.vb, which is a partial class extending the MyApplication class.  We can see that there are some events we can hook into. The Startup event appears to be the first event, so we put our code in there:

Me.IsSingleInstance = Not My.Settings.AllowMultipleInstances

And when we run the app, we see that it doesn’t make any difference.  Apparently we are setting the property too late.  Ok then, we need to move up the ladder.  There is a file buried in the My Project section called Application.Designer.vb.  There is a line in the constructor there that reads Me.IsSingleInstance=True (or false, depending on how you have it set).  So we can set that value to the AllowMultipleInstances setting.  And when we run the app this time, we end up with a stack overflow error.  Why?  As it turns out,  while you are in the constructor of the MyApplication class, you are creating an instance of the MySettings class, which wants an instance of MyApplication, which isn’t done being constructed yet.  So they go back and forth trying to get instances of each other and cause a stack overflow.  Ok, the constructor is off-limits, then.  Besides, that file is auto-generated and you’d lose that change the next time you made any change through the Visual Studio property page. 

Well, crap.  The provided events are too late and the constructor is too early.  There’s no other entry points.  Not true!  This is one of those things that VB programmers can do that C# programmers can’t.  And of course C# snobs would just say “that’s poor coding”, but they’re just jealous.  You can shadow the Run method in the WindowsFormsApplicationBase class, which is where the logic is that handles single/multiple instances.  So in the ApplicationEvents.vb file, where you can extend the MyApplication class, add:

Public Shadows Sub Run(ByVal commandLine() As String)
    Me.IsSingleInstance = Not My.Settings.AllowMultipleInstances
    MyBase.Run(commandLine)
End Sub

And now you can switch between single and multiple instance application settings.  All we did was inject an extra line of code in the Run method, which is after the constructor but before the Startup event.

Wow, I’ve been blogging for over 2 years?