xojoscript and threads

Can a thread in its run event execute xojo script?

yes, it can.

and could that script theoretically update a GUI?

that script can call context methods which than queue update for gui and a timer can check this queue and do the updates.

Ok back to the timer and queue…

yeah there’s no magic way around threads can’t update the UI

awsome to have people that keep trying … it pushes something to the limits and create new paths.

Oh I have no issue with folks trying.
The simplest seems to be to create a thread subclass that has a constructor.
The constructor takes one, or maybe an array of, RectControls as “the things to update as the thread runs”.
In the constructor you create a timer and set its period to whatever (maybe really frequent or not).
Create a method in the thread that is the Action event of the timer with add handler.
Have your thread code populate some properties that are “what should be pushed out to the controls when the timer runs” - whatever that might be.
Run the thread and when the code added using add handler runs you KNOW you are in the main thread and can update the UI.

I think this approach has been mentioned before.
The fact the timer is part of the thread as a property has nothing to do with WHEN its code executes - timers are always invoked on the main thread.

Honestly after switching over the the suggested “best practice” with Xojo threads & UI, our apps seem much more stable than before and I’m actually thankful for the change in Xojo. Not sure why people would spend so much time trying to go around the accessing UI from thread limitation when it takes less time to do it right and results in a more stable product.

It just seems to me that by default a window and application should have a message queue that tells it what to do. Just like win32s.
Its using the timer to service the queue that I dislike… generally speaking i hate polling.

I have been debating the structure of the queue such that one can issue commands to the window that are processed by the timer.
as mentioned above message = [command, arg, arg, arg]

I’m thinking that the message queue ‘could’ be a list of string()s that the timer can exectute as xojo script.

[quote=51127:@Brian O’Brien]It just seems to me that by default a window and application should have a message queue that tells it what to do. Just like win32s.
Its using the timer to service the queue that I dislike… generally speaking i hate polling.[/quote]

A zero-period timer that fires once isn’t the same as polling.

So one sets the timers period to 0, mode to single, then enable it?
This causes an event to be fired once and in that event handler and you can decide if you need another?

[quote=54060:@Brian O’Brien]So one sets the timers period to 0, mode to single, then enable it?
This causes an event to be fired once and in that event handler and you can decide if you need another?[/quote]
Can I just point out, I do not think a timer would work with the period of 0, you should look at using the period of 1 as I do not think 0 is a valid period.

You’re right, you should use 1 instead of 0. However, the framework will set it to 1 when you enable it, so it actually will work.

A timer of mode 1 with period 0 is valid.

So is there a difference between 0 and 1? Is 0 an instantaneous event or does the event happen 1ms later?

0 means “next iteration of the event loop”.