This is a new design-time property on the Window class that appeared in 2007r4, and it appears that some people are confused by what it is, and why you'd use it.
Before you can understand why you should care about this new property, you need to understand what an implicit instance is:
Since the dawn of REALbasic, you have been allowed to refer to windows by name as if they truly existed. If one didn't exist, one would be created for you -- and everything was magical and wonderful and so forth. Essentially, a window's name implicitly meant that the window would exist, so code like this:
Window1.Show
would not cause nil object exceptions, but would instead call Show on the implicit window instance referred to by the Window1 name.
However, this convience leads to confusion, and confusion leads to bugs. The confusion stems from the fact that you have no real good idea as to what Window1 actually refers to. What happens if a Window1 already exists? What happens if you just closed the last Window1, but are still in one of its events? For instance (taken straight from the forums, where this question comes up once every week or so):
SomeWindow.BackColor = &cFF0000
That will actually create and show a SomeWindow object (assuming .Visible = true, which it does by default). And it's very hard to track down why you suddenly have windows popping up all over the place without ever calling Show yourself!
So how does implicit instantiation actually work? We all know that it's just REALbasic code at some level, so let's take a look at what happens. To understand this, you have to realize that a window object is more than just a class which inherits from Window. Check out this post for the background you need.
So an implicit instance is nothing more than a global method in a module that has the same name as your window object. So, for a Window named SomeWindow, you'd have:
Module SomeWindow
Class SomeWindow Inherits Window
// Window stuff here
End Class
Global Function SomeWindow as SomeWindow
dim instance as Window = FindImplicitInstance // How it works is unimportant
if instance then return SomeWindow( instance )
return new SomeWindow
End Function
End Module
Ok, now that you understand what implicit instances are, and how they work, it's time to delve into the ramifications of what they mean.
The first thing to note is that SomeWindow *must* have a public Constructor otherwise that code cannot compile. That means that you can never make a singleton of SomeWindow, which is a fairly large drawback to OOP programming. Another problem is with the fact that you can never enforce using a constructor which takes no parameters (which is another manifestion of the previous issue). This suggests the biggest problem: you have no control over this rendered out code. If you want to ensure certain things (such as always using a particular constructor to create the window), there is no way to do it. What's more, the failure case can easily go unnoticed because you not only get no compile error, but you get a functioning window! Sometimes, the only way to notice the issue at all is when you suddenly get two instances of the same window open on the screen at once!
This is why the ImplicitInstance property was created. It is a design-time way of telling the IDE, "I don't want an implicit instance for this window." It boils down to telling the renderer, "don't generate that silly global method." This gives you the control over your window objects to decide whether it's a quick one-off (SplashScreen.Show), or an integral part of your program design.
My personal recommendation would be to always set ImplicitInstance to false -- leaving it on simply allows you to make potential mistakes with no warning. However, the default behavior is to set it to true by default. This is mostly because of existing information floating around -- it would invalidate a *lot* of existing documentation, examples, snippets, etc.
Here's a handy IDE script I would recommend everyone keep on hand which automatically sets ImplicitInstance to false (thanks to Steve Garman for posting it).
Thanks for the mention Aaron but any idiot can see you did all the work on the IDE script.
I have, however, filed a feature request for a new preference. http://www.realsoftware.com/feedback/eyszqvnq
It was a group effort. :-) As for the feature request, I'm on the fence (but leaning towards "good idea"). Ideally, we should just pick the right default for it and away we go. But unfortunately, we can't since that would invalidate so much documentation out there. If we allowed it as a preference, then people who know what ImplicitInstance means can set it. But that means people who don't know what it mean get lost/confused/scared. It's a hard one...