A recent discussion lead to an odd question. Why do you need to subclass things in Xojo ? Whats the point since they give you all these great controls and classes ? What would make you WANT to subclass things instead of just implementing the events of the existing controls ?
I was sort of surprised at this. And I can see where this line of thinking has some merit. It’s not often that I will subclass something like a pushbutton. I just use them as is from the library in the Xojo IDE.
And for many things this is true. They are perfectly suited to the task I need to accomplish as is. But, often, they aren’t. Sometimes I can make an instance do that tiny little bit special that I need just by implementing the various events. When I I need something special about how a listbox draws itself I can often just use the various paint events that it provides to do the customization. If I only need to do this customization once then a subclass may be more effort than I really want to invest.
But if I have several places where this same customization is required I’ll create a subclass, write my custom drawing code once in the subclass, and then put instances of this subclass in the many places its needed. It keeps me from repeated copying and pasting the same code over & over into multiple instances all over the place. And I also don’t have to remember to fix each one when I find a bug or need some additional tweaks to how things work. I fix the code once in the subclass and ALL instances now get that behaviour without touching each one.
Some times I need much more than just custom drawing. And that’s when I will choose to subclass a control to add some special behaviour to that subclass. A recent discussion was about how to make the SelectAll menu item behave in a special way for a specific listbox. In a subclass I can add menu handlers to handle Select All as well as many others – something I cannot do in an instance on a layout. There is no way to add a menu handler to an instance.
The other thing that a subclass will let me do is add new events that I can then implement in the instances I put on layouts. I can add new events for all kinds of purposes – even to ASK the outside world for more information about the environment the instance is running in (more on that in another post about events). Or you can add something like a “BeforeKeyPress”, “KeyPress”, “AfterKeyPress” for a control where you need this sort of functionality.
In addition to adding new events you can, in a subclass, hide existing events that the superclass exposes that your do not want your subclass to expose. You simply add the event handler to your subclass and do NOT leave it exposed to the rest of your code. You don’t have to put ANY code in the event handler.
Subclasses not only let you add new events, they let you add properties, methods and just about any other kind of code item you can think of. All of this can be open to the public or for private use only.
And the BEST thing about using subclasses is that your code then becomes much more self contained and reusable. You can alter the subclass code and not worry about whether altering that subclass’ code has somehow altered something else outside of its control. It limits the amount of side effects your code in the subclass can possibly cause.
Subclasses are for taking a more general purpose class and specializing it to do something unique.
Take advantage of that in your own applications.