Windows; a weird odyssey

No, not the OS -- the REALbasic object. ;-)

A Window object is a rather strange beast, and I'd like to take a moment to explain the way it currently works so that you can get a better understanding of why some things are they way they are. However, I'd also like to stress the word "currently" since that's important. This isn't a promise that things will stay this way forever -- stuff changes, trust me. So use this as more of a primer to understand a bit about how stuff works under the hood, but not as a definitive tome as to how things will always work under the hood.

When you make a new Window in REALbasic via the Project->Add->Window command, what you really get is a whole lot of black magic. But all of that magic has to translate down into source code at some point so that it can be passed off to the compiler. This translation is called "rendering", btw.

When you compile your project, your windows are rendered into a collection of fun stuff. Let's start out with a simple example. Let's say you have a window that's totally empty. No controls, no code, nothing. When it's rendered, what you wind up with is a module, a class inside that module, and a global method in that module. The module is there as a logical container for everything (a namespace, if you will). The class is what represents the Window class itself (it inherits from Window). The global method is for implicit instatiation.

Have you ever wondered why you can't give a window a protected or private constructor? If you try it, you'll get a compile error for your efforts. You can thank implicit instatiation for that. You see, if you give the window class object a private constructor, then the global module method can't have access to it. So that's what causes the compile error. Neat, eh? If only there was a way to turn implicit instatiation off for a window... :: grins :: (and no, I won't say anything else about the subject, so don't ask.)

Ok, so you may be wondering -- why the heck does it work this way? That's really strange! Well, a slightly more complex example may help shed some light onto the subject.

Let's say that you now have a window with a few controls on it and a menubar attached to it. When you go to compile that project, the window is still rendered like I descibed above. However, each item on the window (the controls you've dragged onto it) are also placed inside of the module. This is an important point: when you drag a control onto a window, you get a subclass of that control under the hood. This means that those controls also have to have a public constructor -- otherwise the window wouldn't be able to create an instance of the subclass! There is some magic that happens under the hood whereby the window creates an instance of the control subclass and magically attaches it to the window.

The menu bar makes for another interesting piece of the puzzle. Ever wonder why you're able to refer to menu items by name (FileQuit instead of MenuBar.Child( "FileQuit" ))? That's because there are global methods inside of that module for each of the menu items. So there's a function called FileQuit() as MenuItem which returns the instance of FileQuit on the window.

The moral of the story is: a window is a really special beast with a whole world of its own. A window is not just a class, and so attempting to treat it as one can lead to some unexpected results. As a user exercise: why can't you inherit a window layout?