What’s the current status with subclassing DesktopWindows/Containers? Is it possible/approved? What I want are subclasses containing common code (methods, properties, event definitions). Not UI elements (although that might be useful).
I know you used to be able to do such things, but I just want to get a feel of whether that is possible in current IDE versions, and “legal” (i.e. isn’t going to fail nastily in the future).
…and I should say that, no, interfaces won’t cut it for what I have in mind.
Why not adding an empty Class (e.g. name = CustomWindow), set it’s super to DesktopWindow or DesktopContainer, add all methods, properties, events you want. Next, set the super of Window1 to CustomWindow. Your Window is now a subclass of CustomWindow.
This method was intentionally destroyed for iOS (the framework just can’t handle it I guess). Can you confirm that this does indeed work with DesktopContainer?
Window1 would not be a subclass of DesktopWindow but its parent class would be a subclass of DesktopWindow, all in all Window1 would be an indirect subclass of DesktopWindow. What would that change ?
I checked the whole thing, since you asked, for iOS as well. This also works for MobileScreen and MobileDesktopContainer.
Yes it does. I just checked it in response to your question.
If I understood @Paul_Rodman correctly (can you confirm), he was asking for a way to create subclasses of a Window or Container including Properties, Methods, etc. and apply them to other Windows or Containers. That was my approach.
Proof!
cWindow is a subclass of DesktopWindow which has a property called “foobar”:
Window1 is a cWindow:
Possible: Yes
Approved: Yes (my guess), because I can ‘right click’ on the Window Icon and create a subclass
What you can’t do (either now or before) is to subclass a window with controls on it, and I think this may be a little confusing for new users. Methods, properties, functions are all fine in the subclass, but nothing visual.
To accomplisht that, you need to use a ContainerControl instead.
As I understood it in the past, subclassing Window was all you could do. i.e. not subclassing subclasses of Window. Then it was seemingly OK unless you added UI elements to the subclass you would be subclassing from.
I know how to do it, but is it something that’s fine to do, or is it something that’s undocumented and might cause issues in the future?
I wasn’t clear in my original post. What I meant to say was: is it legal to subclass another subclass of DesktopWindow if that subclass does not contain any UI elements.
It would seem it can’t be done. You get a compile-time error. So I guess it’s back to the drawing board.
Thanks for all the updates! Glad to know iOS has been fixed too.
I think you are still not being clear?
The answer is yes - it is legal to subclass another subclass of DesktopWindow.
Here is proof: Window1 is a cWindowSubSub which is a subclass of cWindow which is a subclass of DesktopWindow:
Perhaps you mean to ask a different question?
“Is it legal to subclass another instance of a DesktopWindow subclass”
It would seem that if you add a second window to your project and change the first window’s superclass to that window, it doesn’t work (won’t compile).
However, if you add a class to the project and change its superclass to DesktopWindow, then the first window’s superclass can be changed to inherit from that class/window.
This feels like a hack that will fail in the future. Also, the DesktopWindow subclasses do not appear in the Library under Project Items. It kinda smells weird to me…
So you are trying to set Window1 super from DesktopWindow to Window2?
Yes
From another forum:
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”?
Because it’s not.
Eliot said the following in 2017:
This implicit instance setting is very confusing. Xojo should instead create code that opens the window and executes on startup: “Look, this is the code to open a window and there’s nothing magical in the background to confuse you.”
