I made this question some time ago but I got no answer.
That time I could change my algorithm, but I’d like to know. how it works.
Xojo is event-driven programming and we have been told by Xojo engineers (many times) not to rely on the order these events are called, mainly Open events of controls and windows.
My doubts is:
Are events synchronous like threads? Is it possible that the program flow goes from the middle of one event to another and then come back to the first event to finish it?
Or each event code must be finished before another event code can start?
An event is really a method - once it starts running it finishes. Since events run on the main thread, I’ve not seen places where there are multiple events running simultaneously. I don’t think that’s possible.
Some events are driven by coding in the program or framework itself. Others are raised by the OS (like in the case of a socket receiving data).
So I don’t think that an open event of one control can start and half way through, the open event of another control starts. I think everything has to be queued and run sequentially. The order though varies. From what I’ve seen the order varies most definitely between Windows and Mac OS. But it could probably vary between runs of the app on the same OS.
Euhhhh, no. We had a discussion about this. If a Timer fire while a code is running (not a Thread, but an event or a Method) then its code is execute. The code of the Event-Method wait and go on after Timer (*?).
: In fact I don’t know if the two codes are execute Simultaneously or not.
I say that for Cocoa App, I don’t know on other build.
[quote=200375:@Daniel Taylor]I can remember a time (no pun intended) when Timers did interrupt other main thread code on Windows, but never on Mac OS. This was changed and I haven’t tested this in years.
I’ve been under the assumption that Timers were not supposed to do this any more. Very interested if this is not the case on Cocoa.[/quote]
I just tested with a loop that keeps running for 20 seconds in a button Action. Timers are held hostage until the end of an event.
App.YieldToNext does not suffice.
App.DoEvents in the loop is the only way to allow the timer to take place while the Action event is not over.