I have a subclassed generic Listbox I use a lot, which has an added an Event Definition for “ColumnWidthsChanged”.
In my current project, I have subclassed this subclassed Listbox (so I now have a subclass of a subclass). I want to Raise the event ColumnWidthsChanged in a method, so I write:
RaiseEvent ColumnWidthsChanged
And it doesn’t work. Xojo tells me “This item does not exist”. But it does exist in the parent class (my subclass).
If I try to add an Event Definition for ColumnWidthsChanged to this sub-subclass, Xojo says “This property has the same name as an event. You must resolve the conflict.”
Obviously I’m missing something. How am I supposed to raise this event?
Yeah, I thought of that. It works. But it’s clunky. Inelegant. I mean, I’d like to be able to use RaiseEvent directly, instead of calling a method that then raises the event. I guess the answer is simply “you can’t do that”. Which seems a little silly.
Yeah, what’s weird is that the sub-subclass DOES inherit the events. They just can’t be called using RaiseEvent in the sub-subclass. I find that unexpected and confusing.
There is a difference between adding an Event Definition to the subclass and adding an Event implementation to the subclass. You can add Event Definitions and keep raising the event in as long a chain of subclasses as you want.
The only place you can use RaiseEvent (or call an Event) is on the class that contains the event definition. In particular, you cannot raise an event from an subclass, an instance of a control on a layout or from outside the class. If you need to be able to call an event, you will have to create a companion method on the initial class that raises the event.
There is no such limitation. Raise event calls the event in the subclass of the current class, not on the current class itself. All subclasses inherit the events of the parent class until one of them implements that event. The event terminates at that class unless it adds an Event Definition and raises it. Then the inheritance chain continues.
I would say this behavior makes perfect sense. The super class uses a certain condition to raise an event, based on logic hidden to the developer. By raising the same event again from your subclass with parameters that might or might not be the same as the original ones, you could introduce erratic behavior. The event could fire twice, once invoked from the super class and the next time from the subclass.
The same applies for custom class hierarchies, although you can always use a protected super class “Raise” method if you are certain you do not cause trouble by this.
The best ways to avoid possible misbehavior are either to forward the super class event by not touching it, or otherwise to intercept it with an event handler and to fire a copied event (possibly modified to your subclass needs) independently or from within the handler.
Xojo seems to have read this thread, too… and they’re considering the current behavior to be worth investigating: <https://xojo.com/issue/52260>
Ok, that currently does not mean anything beyond its been reported.
This may well be closed as not a bug and by design as its been this way forever.
Not a good idea as it breaks the encapsulation of the event logic embedded in the super. Unless the super explicitly provides a mechanism to raise the event from the outside, the subclass shouldn’t be able to unless it implements the event, thereby complying with the logic embedded in the super and possibly adding some logic of its own.
This is why the feature request explicitly states that the event “is not implemented in the inheritance chain”. That is an exception, and the only case in which it makes sense for the subclass to be able to raise the event.
The proposed behaviour would require that an identical Event Definition is added to the sub-subclass. So essentially Xojo would see that the same Event Definition exists in both the subclass and the sub-subclass, check that it is not implemented in the subclass (or however deep the inheritance chain would go), and only then would allow it in the sub-subclass instead of giving the “This property has the same name as an event. You must resolve the conflict” compile error message.