[quote=87515:@Matthew Combatti]Thom,
I believe you since you’d know the under-the-hood specs of the framework… but help me understand as it defies logic…
Aside from the main topic this has me curious then, as, if any class within a thread accesses the UI, it thows a ThreadAccessingUI error message correct? (True)
So creating a timer (class) in a thread (if its truly part of the main thread) should throw a “ThreadAccessingUI” error as the new thread would conflict with the main thread and UI (but it doesn’t).
In Windows using C++, the proper method to prevent lockup of the main thread, which I implemented in Xojo (and seems to work as it should with better performance than a timer alone…if the timers all exist within the same space it should render the same result if implemented in both ways??? But doesn’t…), would be to create a thread using api and within the thread create a timer using i.e. SetTimer(1000, pointer) api… which allocates the timer in the thread. I assumed Xojo did the same as it would be “best practices” and works with comparable noticable results between xojo and c++ using both methods. So you’re saying whenever a timer is created in Xojo, its actually an underlying “array of thread handles” created in the main thread with all WM_Timer messages being handled in the main app message receiver?
[/quote]
Depending on what API you used to create the thread you may in fact end up causing yourself reentrancy problems.
The Xojo framework is NOT reentrant and using a preemptive thread to call back into is may work most times but will really be masking fundamental issues that cannot be worked around in pure Xojo code.
As far as I know Timers are NOT fired using WM_Timer messages - hence why timers CAN actually only be approximately accurate.
If there is long running code that blocks the main thread from being serviced then timers could miss a call.