REALGetEventInstance fails for subclassed controls on window implementing event

SDKs Plugins
1

Imaging a plugin implementing a control.
The the initializer the plugin checks with REALGetEventInstance if a given event is implemented.

Now the control is subclassed.
And that subclass is used on a window.
And on the window it implemented an event.

If the even is implemented in the window, REALGetEventInstance returns nil above.
But if implemented in the subclass, it’s seen.

I think that’s bug. Anyone else run into this?

I think the stuff should be setup correctly before calling my initializer, so REALGetEventInstance can find the events implemented in sub sub class.

2

<https://xojo.com/issue/46897>
reported.

3

I agree that this might be a bug.
I can confirm this with Real Studio 2012 as well as with Xojo 2016r4. So it’s been around forever. I wonder why no one has noticed that yet, though.

There’s at least a work-around, if a pretty annoying one: One has to implement each of those events in a subclass of the plugin’s control and then forward them as new Events of this subclass.

4

[quote=314325:@Christian Schmitz]Imaging a plugin implementing a control.
The the initializer the plugin checks with REALGetEventInstance if a given event is implemented.

Now the control is subclassed.
And that subclass is used on a window.
And on the window it implemented an event.

If the even is implemented in the window, REALGetEventInstance returns nil above.
But if implemented in the subclass, it’s seen.

I think that’s bug. Anyone else run into this?

I think the stuff should be setup correctly before calling my initializer, so REALGetEventInstance can find the events implemented in sub sub class.[/quote]

At init time, the control is not ready. At open time it will, but not in the openCallback. It is still too early. register the following:

REALeventInstance kEventInstances[] = {
	{ "Open", (REALproc) _OpenEvent },
};

/*

  • This is the OpenEvent subclassed from the RectControl of Xojo. It is only called in runtime, after the Open function
  • callback of the REALcontrol. Here we require the implemented events by InitializeTargets, and finally
  • provide the OpenEvent to the user, so things can be overridden. Note that we here set the function pointers and not
  • earlier, because some setters used already could call the function pointers.
    */
    In _OpenEvent you resolve your REALevent.
5

Thanks. This seems to work better.
Still I would love to see the events list being available earlier in the process.

6

[quote=314402:@Christian Schmitz]Thanks. This seems to work better.
Still I would love to see the events list being available earlier in the process.[/quote]

You have to realize that first the Window needs to be in place, together with all the controls. Therefore any REALcontrol will come with predefined events. You should have notice this. The OpenCallback, fired before the Open event allows you to set up the control. There are also differences between Mac and windows when it comes to setting up a control in the OpenCallback. This relates to how the operating systems are handling the creation of a window. The best place to resolve events is the default Open event, because then Xojo is able to resolve its own events.

For non guy related stuff I do support your wish. It is unfortunate that when you declare a methodDefinition “Constructor()” which is automatically called by the Xojo runtime, after the InitCallback and OpenCallback, is not suitable to resolve events.

7

My expectation would be that at time of initialization the class pointer is already set, so the REALGetEventInstance could use it when checking the event pointer for the class at that early state.

It would be nice to know how things work internally.

8

It’s not.

Events for objects on a layout are hooked up via AddHandler.