I have had a challenge to convert two apps from Real Basic to Xojo and have come unstuck on the second app with threading and UI updates using tasks.
The first also updates the UI from a thread using a task, based closely on the example app distributed with Xojo.
Like the example app this first app has a super class that is the super thread of the thread added directly as a control to the window. This works fine.
The issue I have is the second, like the first there is a super thread (the UI master thread & Task), and this is the super thread for a child thread created stand alone with in the app. Because some of these threads are used in multiple places and on multiple windows they themselves are super threads of both threads added to windows as controls, and also variables instantiated as threads within code.
LOL Sorry this is a bit hard to explain.
The issue is that when I run the app in the second example and the threads activate, I get a runtime nilexception. And mLock (CriticalSection) and mTimer are Nil for the SuperClass.
I guess my question is has anyone done what I describe previously, and second how do I structure the threads and make declarations so that the thread and ui update work correctly and mLock and mTimer are defined correctly.
You could place the thread and timer into an array of Containers, then place them multiple times wherever you want, each acting independently from one another. Then have a master thread control the threads in each of these containers.
Having reviewed the previous developers code, I’ve realised that all the threads except one have been unnecessarily created as independent super threads, so they can be rationalised to work the same way as the example and the first app.
The last one could, with work, be moved into a container as you suggest.
[quote=370777:@Detlef Kahner]You need to work with properties.
How to:
From within the thread, update the property with new value.
From UI element with Timer included, use the Timer to read the property and set the UI element accordingly.[/quote]
Or: Use a Xojo.core.Timer.Calllater call to a method to which you can forward the properties() as Auto.
All timer action event handlers are run on the main thread so I use Xojo.Timer.Calllater(0, AddressOf ). Method may be defined in the thread class, but will still run on the main (UI handling) thread. The delay of 0 ms just pushes the action onto the next event loop.
