I’m using the Xojo example project Platforms > Desktop > Canvas > Interactive Canvas and I’m baffled about how it works. I can follow most of it but a couple of things are over my head. If anyone can explain what’s happening here I’d be grateful.
There are two Canvas-related objects, called FlowCanvas and FlowChartCanvas. FlowChartCanvas is a subclass of FlowCanvas. FlowChartCanvas has a visible UI but FlowCanvas doesn’t. Why not?
There are a number of (custom) Event Handlers in FlowChartCanvas (which I can follow) that have parallel Event Definitions in FlowCanvas. Also, all of the methods are in FlowCanvas, none in FlowChartCanvas. This is obviously a deliberate design feature, but why?
I suppose the main area of confusion is why there are two objects at all. Why aren’t all of the Event Definitions and Handlers happening in one place (say, FlowCanvas)? It feels unnecessarily complex. I’m sure there is sense behind it, but I cannot understand it. I hope someone can shed light on this.
Is the Super of FlowChartCanvas set to FlowCanvas? If so, it’s a simple delegation of responsibility. The Flow logic is encapsulated in the FlowCanvas object. You can then subclass FlowCanvas into any UI you want.
In theory, the example could have been implemented without Subclassing.
Subclassing helps in several scenarios.
Two common common ones are:
You are going to create several instances of the Object
(As Tim Hare pointed out) You are going to use the Object in multiple UI contexts
As a designer, if you are accustomed to Subclassing, it is sometimes easier to concentrate all your code in a class, even if you think that you are only going to need one instance of it.
Thanks Tim. Yes, in the example FlowCanvas is a superclass of FlowChartCanvas and also a subclass of DesktopCanvas. But that’s still confusing me. I would have expected FlowChartCanvas to have inherited from FlowCanvas, but while FlowChartCanvas has a visible UI, FlowCanvas does not. How is this object made to have no UI while its super- and sub-classes have them?
I can see the idea of delegation of responsibility, but in this example some events are delegated to FlowChartCanvas (I’m guessing that this is why there are event definitions in FlowCanvas matching the event handlers in FlowChartCanvas) while other events (and all methods) are handled by FlowCanvas. I’m trying to understand the design considerations that would make you do this for some and not for others. It looks like the events delegated to FlowChartCanvas are mostly ones that are not catered for in the basic FlowCanvas.
From here, though, it’s not clear (again, from a design perspective) where I should add new events. For example, I want to drop files out of the Finder onto my application. Do I put the DropObject event in FlowCanvas (where the other mouse-y events are) or in FlowChartCanvas? My gut feel is FlowCanvas, but I don’t have a strong rationale.
Thanks Arthur. I think that in this scenario I would like to try it without subclassing. However, I’m not sure how this would work. For example, in the subclass FlowChartCanvas there is a DoubleClickedLink event. This has an event definition in the parent class FlowCanvas. But I am not able to code that event in FlowCanvas; it is not available in the list of new event handlers. I tried deleting it from the event code in FlowChartCanvas and that made no difference).
It’s beginning to feel like the subclass is being used to handle custom events, with those custom events having first to be defined in the parent class. I tested this by creating a new bogus event definition in FlowCanvas called TripleClickLink. This could then be added as a new event handler in FlowChartCanvas but not in FlowCanvas itself.
Am I understanding this correctly?
The Event Handler and Event Definition terminology can be quite confusing in Xojo, especially when SubClasses are involved. There are some good resources available, including YouTube tutorials and several books (check into Eugene Dakin’s books).
If you are trying to recode this example to not use the Subclassing, your first step would be make sure that the Canvas Object on the MainWindow is not subclassed from the FlowCanvas. It should be a DesktopCanvas. Then, you would need to move all the Methods, Properties, etc. from FlowClass onto your instance of the DesktopCanvas. There is a way, in Xojo, to Extract the SuperClass, but that may be more confusing.
I would recommend sticking with the SubClassing in the Example. The Event Definition/Event Handling logic does take a while to learn, but it pays big dividends when you get the hang of it.
It is not necessarily obvious, but the FlowCanvas (SuperClass) does have a UI, in that any Objects that are SubClassed from it, by being added to a Window, have a UI.