As the order of operations for windows and controls is a semi-frequent topic here and elsewhere, I just placed a feedback ticket to get this formally documented within the Xojo docs. If folks would like to see this happen, please thumbs up this feedback item.
Within the ticket, I’ve placed the most thorough information I’ve seen on this from Thom McGrath, but alas it’s a post within the Testers forum so you’ll need to have a valid Pro license to see it.
Upvoted. This is one of the first things I wanted accurate information on when I began to use Xojo.
I don’t think you need a Pro licence to be a Tester. I haven’t got one.
Ah yes, very true as I believe one can make a request to customer support to get added.
They have always said they would only document in of certain cases, Control open events before Window open…
But for most others the order is not documented or guaranteed to be the same Xplatform…
They have been saying that for decades.
-Karen
Then it should be documented per platform. In fact the differences between targets would be good to know if you’re hoping to support, say, both desktop and mobile, with as much common code as possible, or if you want a heads up on differences in how different targets work.
I’ve never used any event model before that wasn’t fully documented.
If it’s inevitably “it depends” in certain cases, then they can so state, preferably mentioning what it depends on.
When I say Xplatfrom I was just speaking of Desktop (mac Win, Linux)…
Ever since I have been using the product (over 21 years), from what I have seen, when someone asked about event order the answer is that outside of a few cases, event order is not documented (implying that was company policy, not an oversight) and not guarantied to be the same X-Platform.
Maybe they will change that.
-Karen
And really not guaranteed to be the same from one release to another. I believe the ones that matter are documented. And Michel’s post the OP references is a bug, so it would go against any formal documentation anyway.
Well that would sort of be a problem for a good many folks, wouldn’t it? Not just knowing what is supposed to happen but also from a breaking prior code perspective. Agreed though that if things are different from one platform to another you couldn’t have universal documentation, but I don’t see why you couldn’t outline each platform as its own scenario.
Awesome and maybe I missed this in the documentation. Can you provide a link?
P.S. Yes, Window.Open event speaks to this, but not to the same extent and depth as Thom’s post here in the forums.
So just to be clear, nothing I’m proposing here has anything to do with Michel’s original post and his bug. The link I provided above was Tim’s response explaining the window versus control open events. Because this topic has nothing particularly to do with Michel’s bug, although maybe tangentially, I created a separate topic for this rather than fork Michel’s thread in another direction.
The Window Open vs Control Open is already documented and guaranteed not to change. There are a lot of event groups that are also guaranteed, like KeyDown vs KeyUp (or whatever they’re called now).
One thing that is not guaranteed is the order of the Control Open events. They tend to happen in the order the controls were added to the window, but that could certainly change if Xojo found a better way to instantiate them. Never refer to one control from the open event of another control. It may or may not exist yet. All operations that affect multiple controls belong in Window.Open, where you’re guaranteed they exist and are set up.
To my knowledge, there is no central place where a list of event order is documented, but the ones that matter are documented in place, as you saw with Window.Open. Best practice is if you are working with an event, check its specific documentation page. In general, if control order is not documented, don’t rely on any specific order.
Do you have one that you’re having a problem working with?
I’m a longtime Rb/Xojo user that doesn’t post here often (was a tad bit more frequent in the NUG days) and actually don’t personally have any issues. I just noticed that there is no formal top level documentation to this similar to how Apple documents the responder chain. Instead a bunch of this is tribal knowledge here in the forums which is why I placed the feedback request for a documentation improvement for all. Especially as the Xojo order of events isn’t entirely intuitive, it might be helpful to have this in the documentation.
Just picked up and looked at my 900-page long book on javascript. This has an 80-page chapter devoted to events, their types, how they propagate, and a lot more besides. Since events are so important in Xojo, a whole section in the docs devoted purely to that would be most helpful.
Looking for an order in events may go against event programming. In essence, each event handler should be self-contained, and not rely on how other events may fire before or after. I feel the idea that events should fire in a given order is a remnant of linear programming.
The need to know that window Opening fires after the same event in controls placed on said window is pretty irrelevant, if each event handler has been devised correctly.
The very fact that Opening happens after all controls have formed is actually an idiot proof way of preventing calls to controls that have not yet been instantiated.
Not correct. Cascades can happen and sequences must be obeyed. When you move focus from one place to another, for example, you must have a LostFocus() first in the control losing its focus (that could be overridden and focus never moved) and GotFocus() after (in the destination control if such focus move wasn’t overridden), if you, as a framework designer does not obey such order, and fire a gotfocus() first and lostfocus() after, you made an engine basically broken.
Key presses are another one. When you type ABCDEF we can’t receive ABCFDE.
Xojo is designed to fire LostFocus only if focus is currently on a control, effectively after GotFocus. Idiot proof.
Again, from the code point of view, it is not necessary to know the order of events, as long as the event handler is coded self-contained, and does not try to reinstate some linear programming in the process.
It’s not linear, but also is not chaotic. Cascades must be obeyed, some orders should happen.
Again, Xojo takes care of all that. Cascades are managed by Xojo.
No need to second guess the platform.
Further, the event should happen on the object before it happens on the parent, and before it happens on the grandparent - if that does happen at all. The docs rarely make it clear whether an event gets passed up the hierarchy like that or how far it goes up and how you stop it propagating on from the parent or even if that’s necessary.
If you are taking about subclasses then it keeps going up unless handed…
If you are talking about control hierarchy embedding hierarchy… that would normally not make sense…
If there is an event on a button why would anything get passed up to the parent container (be it a a window or another control)
-Karen
There are some events (can’t name one off the top of my head) where the control’s event handler can indicate by its return value that it doesn’t want to handle the event, and so the event should be passed to its parent control. In HTML/javascript/the DOM the reverse is true: events are passed up (and down) unless you explicitly prevent that from happening.