In a project when you INSERT a new window you are creating a new INSTANCE of a window
Not a new class
You cannot use a Window INSTANCE as the super for another window
(which is why you cannot inherit UI)
In order to make a superclass you add a class, make ITS super DesktopWindow (or Window in older versions) and then make your Window instances use this new class as their super
This has ALWAYS been this way - literally since I can remember
Not a hack in any way
That makes sense (sort of). But if those are instances, why can you create one or more instances of those items programmatically using “new”?
Well Windows are weird
What you create in the IDE is not a CLASS in the conventional sense (not like INSERT CLASS)
And its not a MODULE
Its an INSTANCE TEMPLATE (really)
But at runtime its dealt with differently and there IS a a module with a class named the same thats in the module.
The IDE takes the template you created in the IDE and writes this out this way
So at RUNTIME there is a class which is why you can say “New WIndow1”
This is a runtime detail and doesnt help you in the IDE in any way
This is actually detailed in a blog post by Aaron Ballman and I think its in his book as well
https://web.archive.org/web/20071015210521/http://ramblings.aaronballman.com/2007/06/
By
Aaron Ballman
on June 5, 2007 8:00 AM
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?
Heh
Oh its more than confusing
It makes so you CANT put Window in Modules
Why ?
Because when a window is rendered out to compile its a module with a class inside it
IF you put that inside another module now you need a class that is nested 2 levels deep to be GLOBAL and that doesnt work
IF the IDE just inserted the right code into App.Open that created a new instance and got rid of implicit instance then you COULD put windows inside modules
Because it would JUST be a class
That might have other issues - like scoping etc but at least it would be possible