In my program I have a module which contains a LoadSettings method with all the necessary things for the app to roll. I called it from App.Open. But in the main window, I was not getting the loaded values.
Until I set some system.debuglog and found out that the MainWindow.Open event was called before the App.Open one.
I kept reading that events may not fire in the order we expect them too, this is the first time I bump into it. I will never again assume any intuitive order 
Do you use implicit instance for the window? If yes, it could change to not use implicit instance and then create your window in App.Open.
You are right. LoadSettings contains a reference to the window’s object. So it triggered the instance. Thanks.
I have many bite marks on my derrire from that gotcha. So many that any new projects have the “Implicit Instance” checkmark turned off on all windows and I create instances of my windows manually.
It would be handy though if there was some kind of reliable order.
In these cases, it’s not order that’s the culprit since the runtime does exactly what we tell it to do. If you refer to an implicit window in another section’s Constructor or Open, that implicit window will respond and happily open itself.
Controls get their open event before the window
Thats about all you should rely on
Indeed. I had not realized it at first.
[quote=108763:@Norman Palardy]Controls get their open event before the window
Thats about all you should rely on[/quote]
That is what I discovered : a listbox open event on that window fires before the window open event.
There is, you just have to track it 
[quote=108775:@Michel Bujardet]
There is, you just have to track it ;)[/quote]
There isn’t beyond the controls get the open event before the window
Anything else is subject to change - and not a bug if it does change
[quote=108793:@Norman Palardy]There isn’t beyond the controls get the open event before the window
Anything else is subject to change - and not a bug if it does change[/quote]
This little story taught me at least a lesson : never assume anything about events order, and you confirm it. Like many old programmers, I come from the procedural era where execution started at the beginning and flowed in rigorous order.
Now thinking in terms of self contained events has become natural for me, but still sometimes I encounter the concept of need for synchronisation. In the logic of my project, and after coping with LoadSettings, I just found out that calling SaveSettings right from App.Close could interrupt the file write to disk because the app quitted before all data had been written.
I thought an event did not relinquish execution before it was complete, but it seems Quit can simply stop it.
Basically when I’ve seen people want predictable event order its for things like loading a wind & its controls in a specific order.
So they know that when control A’s open event runs that Controls B’s has already run.
If thats what you need do that set up in the Window open event as you CAN be sure all the controls open events have run.
Beyond that there are some other predictable sequences for various controls - mouse down happens before text change.
That sort of thing.
So there are some predictable orders.