Just for the record (and as personal reminder) i tested the flow of events when opening a web app.
This App has
a default WebPage,
controls on that WebPage
a webContainer on that WebPage
controls on that WebContainer
- App.Open but no communication yet
So it is sort of in outside-in inside.out flow.
When a WebContainer is called dynamically, the same flow appears:
And somehow the numbering was messed up. It off course counts from 1 to 10.
Don’t rely on event order. Open will always be before Shown, but the order in which the Shown events fire may not be consistent.
This list was based on tens of testing rounds.
I did this test because i want a fully controlled flow in my app. In normal web development flow is obvious, especially with use of the MVC paradigm. In Xojo it is not as obvious.
Is the conclusion then, that Xojo is not consistent and should not be used for complex projects?
Is the conclusion then, that Xojo is not consistent and should not be used for complex projects?[/quote]
More that a reliance on ordering is a dependency that you should avoid
I should have been more clear. The Shown events will always happen after the Open events, but the Shown events will not always happen in the same order in relation to one another. It has to do with Internet latency. All of them leave the browser at the same time, but won’t necessarily arrive at the server in that same order.
Given the answers above, my confidence in Xojo decreases.
I presume that the Open- and Shown-events are invoked by the Xojo-scripts. So Xojo should always be consistent in this flow. How my browser communicates with the server is another matter, as is the flow of when things are shown in the browser.
Simply answering that one should not rely on this flow is impossible for complex systems, where containers and controls are generated dynamically. If I wanted to build static websites, I wouldn’t use Xojo, but Windows Notepad instead.
So: can Xojo supply the users with a flow-chart that is accurate?
Open will always happen before Shown, but the order in which the other events fire is highly dependent on network latency, especially if there is something happening very quickly on the browser.
Mostly what I was trying to communicate was that platforms differ greatly in the way events are triggered, so the event order on Mac is slightly different than Windows and slightly different than Web. You should not rely on a platform’s event order to work everywhere else.
We are talking about the Web version here of course.
If we do not know what element fires the Shown event first, then can you at least tell me what element fires the Shown event last? What is the last event before a complete Web app is started by a visitor? Without this, one cannot build a proper app without the risk of null objects.
Create a timer, one shot, 500ms period. Do all your initial control manipulation in its Action. This should eliminate the setup problems.
Thanks for the nice work around.