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.
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.
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.
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.