And no… Xojo does not reveal the “subclassing” code that created the “built-in” controls… that is all within the framework (I assume)…
But “technically” you could re-create any/all “builtin” controls yourself… just start with "Object’ and begin subclassing away 
[quote=17176:@Joey Coyle]Hi Norman,
But then what it’s showing is wrong. Because when I drag a ListBox onto a window, the name shows ListBox1 and super shows ListBox. If the instance knows what it’s Super Class is, why is it showing the Class here? The superclass, as stated by Dave above, is RECTControl. Or are you saying, it is an instance of the class ListBox1, and ListBox is the super class?
Also, the documentation on page 11 of the book 2 of the new documentation should be changed, because it states that subclassing is happening.[/quote]
The Super for any object (whether an instance, or another subclass) is the class that that object is derived from. The Super itself can be a subclass of another class, but what is displayed as the Super is the class it is directly based on. You could create a subclass of ListBox called ‘MyListBox’, and when you put an instance of that on a window, then ‘MyListBox1’ has ‘MyListBox’ as it’s super, which has ‘ListBox’ as it’s super, which has ‘RectControl’ as it’s super.
The “Super” is not the topmost class that an object is based on, it is one level up from the current class.
Hi Mark,
I understand what should go in Super.
We are saying that xojo is using the super field in the inspector inconsistently. For App and Window1, they are showing the class that App and Window1 was derived from correctly, which is Application and Window respectively. But for controls like ListBox1, they are putting the class name in the Super field, and not the super class. Because I am told ListBox1 is not a subclass of ListBox, it is an instance of ListBox
In your first post you state…
Go to xojo, drag a ListBox into a window, select the listbox instance, and open the inspector. It will show super as ListBox, so your quoted statement and what I see in the inspector can not both be true.
thanks,
joey
[quote=17211:@Joey Coyle]Hi Mark,
Go to xojo, drag a ListBox into a window, select the listbox instance, and open the inspector. It will show super as ListBox, so your quoted statement and what I see in the inspector can not both be true.[/quote]
No, that is exactly what that means. Listbox1 is an instance of the ‘ListBox’ class, hence it’s super is ‘ListBox’ (the class that it is based on). I should amend my statement from before that the “Super” is not the topmost class that an object is based on, it is one level up from the current class or instance.
ListBox1 is not based off of ‘RectControl’; it is based off of ‘ListBox’, which in turn is based off of ‘RectControl’.
Hi Mark,
If that is the case, I feel xojo is changing the meaning of computer science terminology.
One problem I see in your description is the use of the phrase "based off "? I think that is too vague. We have two distinct things we are discussing. Subclassing and class instantiation.
With regard to an instance be “based off” a class, and calling that class it’s super. I have never heard of this?
an instances super usually refers to an instances super class. Take an objective-C instance.
If I call self on an instance, I get the methods available to that instance based off the Class. If I call super on that instance, I have the methods available before they were overridden, in the super class.
[quote=17133:@Joey Coyle]Sorry, my mistake. When I add a method, it adds to the Window containing the control, not the ListBox.
I will restate this…
So if I add a method foo to Window1, I can then call Window1.foo
Is Window1 a subclass of Window or an Instance? I can add methods to it. And in the inspector it shows Window is Super of Window1, just like for ListBox1 it shows that ListBox is Super of ListBox1.
[/quote]
Here’s a little wrinkle. Window1 is an instance of Window, but it is more than that, too. Window1 is more like a cross between subclass, instance and module. The IDE generates a lot of behind the scenes code for Window1. It acts like a subclass, but you cannot make a subclass of it. But you can make instances of it. And it acts like a method call.
A window in your project is a special case. It doesn’t fit the definitions exactly. I guess it really acts most like a special kind of subclass.
Terminology as per Wikipedia link text:
[quote]Classes can be derived from one or more existing classes, thereby establishing a hierarchical relationship between the derived-from classes (base classes, parent classes or superclasses) and the derived class (child class or subclass)[/quote]So the expression “base class” is a synonym for “super class”.
[quote]an instances super usually refers to an instances super class. Take an objective-C instance.[/quote] This is wrong. Besides that I don’t understand what you mean with “refers”, it’s working the same way as with Xojo. Instances do not have a superclass - a class has a superclass (unless it is a root object like NSObject).
When a class has a superclass it means that all instance variables and methods of the superclass (unless scoped private in the superclass) are also instance variables and methods of the class. If you ask an instance: “Of what class are you?” the answer might be NSView, if you ask what its superclass is, the answer will be NSResponder. This means the instance is not only an NSView, but it IS also an NSResponder (and an NSObject) at the same time.
[quote]If I call self on an instance, I get the methods available to that instance based of the Class. If I call super on that instance, I have the methods available before they were overridden in the super class.[/quote]You surely meant: “…before they were overridden in the class.” And yes, that’s how it works in Xojo too.
Windows: they are special in Xojo. I assume - as Tim Hare mentioned - that there is a hidden subclass from which an instance is then created. If you do introspection on a window, the name is something like “WindowXYZ.WindowXYZ”, while my window class name is only “WindowXYZ”. It works fine, so why bother…
[quote=17176:@Joey Coyle]Hi Norman,
But then what it’s showing is wrong. Because when I drag a ListBox onto a window, the name shows ListBox1 and super shows ListBox. If the instance knows what it’s Super Class is, why is it showing the Class here? The superclass, as stated by Dave above, is RECTControl. Or are you saying, it is an instance of the class ListBox1, and ListBox is the super class?[/quote]
Yes
see http://documentation.xojo.com/index.php/Listbox
in the top right you see “inherits from”
In this case the inheritance is Object > Control > RectControl > Listbox
and you put an instance of a listbox on your layout - the instance shows you what class it is an instance of.
Windows ARE special - they look and appear like classes and in MOST respects behave like them.
The reason is that, as others have alluded to, there’s a fair amount of code you don’t have to write that DOES have to exist to take the layout you draw & make it all come to life - and then there’s the “implicit instances” which somehow have to construct & set up a window just as you drew it when you simply do
window1.showThe IDE generates all kinds of code - much more than you might guess - hence why windows behave the way they do without you having to call constructors(unless you want to) etc
We’ve talked about making windows NOT be quite so special but tests showed that it would break a lot of existing projects if we turned windows into outright classes and not the way they currently are.
True
True
True
That’s great, we will use those as working definitions.
If I have an instance of NSView called view.
NSView *view = [[NSView alloc] init];
I can then call methods from the class or the superclass.
Say NSResponder defines a method called methodName, and NSView over rides methodName.
If I do…
[[view super] methodName]
I am calling a method called methodName with the implementation as defined by the superclass, and not as defined by the class. The instance is of NSView is aware of the super class NSResponder.
I know this a “yeah so, duh” moment.
The reason, I was explaining this.I was just responding to a comment that in xojo “super” can mean the class from which an instance is defined. Do you find this true as well? Do you agree that if I do Object myInstance = new Object, that Object is “super” here. I do not.
[quote=17234:@Norman Palardy]Yes
see http://documentation.xojo.com/index.php/Listbox
in the top right you see “inherits from”
In this case the inheritance is Object > Control > RectControl > Listbox
and you put an instance of a listbox on your layout - the instance shows you what class it is an instance of.[/quote]
Thank you Norman,
I think I understand, these things, Controls, Window, Application aren’t really Classes that follow OO principles. This is also the point that Tim made above, so thanks Tim.
I sincerely ask if everyone can just please give me the benefit of the doubt, and believe I understand Object Oriented principles. I really don’t want to talk about that anymore.
That being said…
If you go to xojo, drag a ListBox into a window, select the listbox instance, and open the inspector. It will show super as ListBox. Showing the Listbox as “super” is just confusing, as it does imply something from the OO world, and probably just another word should be chosen for use in the inspector.
...that in xojo "super" can mean the class from which an instance is defined No, it can’t.
Great Lukas, we agree!
I agree. They should probably change the label from “Super” to “Class” when you’re dealing with an instance.
From what it seems to me, because you can add properties and methods to ListBox1 in this particular case, there must be some kind of over-riding and subclassing going on to make that happen. If I add a property ParentWindow to ListBox1, it adds an item that wasn’t in the original ListBox. So in a more classical OOP paradigm, ListBox1 inside a window defines a subclass in addition to instantiating it.
I suppose in Javascript terms though, one can add “properties” to “objects” at runtime and so maybe the distinction has blurred a bit.
If I drag LIstBox onto the Contents area as opposed to into a Window, Xojo looks exactly the same. I can create properties for the CustomListBox that gets created as well. But that’s not an instance. I have to instantiate it first, by dragging it into a window or with a new operator.
If I instantiate it with the new operator though, I don’t think I can add further properties to it. So again, if I drag CustomListBox into a window, it must create some kind of subclass of it behind its instance that I can then add properties and methods to that aren’t in my original CustomListBox.
You can not add a property or method to an instance of a control or container control. If you highlight a control in the IDE and then choose “Add Method” in the menu, the method is added to the window, not the control.