In the desktop section of the examples there are two programs showing ways of updating the UI using threads. One of the examples is using a task, and that one I can’t see how to move from the example program to my program, because the task is a subclass of a thread (I think). How do I work around this? I’ve never worked with threads and while I’ve subclassed in other languages never in XOJO. I have a large app with many UI objects but they are all maintained from a single method so the UITask method seems doable … if I can get it or create something like it in my application. Can someone get me pointed in the right direction please?
ok, I figured out how to get a task up and running but I have two questions:
- Can I pass values to the via the run method and if so how?
- Can I get UpdateUI to pass back a value to Run allowing for the control of the timer to happen in the updateUI method and how?
- It’s an Event, wouldn’t touch this, set properties and use them in your run event. I often use a dictionary to store all parameters i need.
- Yes, the Task example hows how, think it is a array or dictionary (can’t remember exactly) that get’s passed back
Thanks Stefan, I’ll try both today!
I was able to get the Task version in place but it keeps crashing. My goal is to call a method from the new thread where all UI elements are updated, not just pass a value over. Are there any third party controls that makes this easier or even tries to mimic the VB6 DoEvents functionality for desktop development?
@Doug: this is one of the fundamental principles of how Xojo works. How and where is Xojo crashing? Do you get a ThreadAccessingUiException? You need to call a timer in your window, which then updates the UI.
There is no equivalent of DoEvents for desktop. There is a third party plugin that helps with your situation. See https://www.monkeybreadsoftware.net/process-calldelegatesmbs-method.shtml . The plugin is huge but worth every Euro cent.
Thanks Beatrix!
If you think you have to use DoEvents in your Xojo desktop application please think again. It’s not recommended and interferes with the overall event processing. We use threading a lot and don’t have any issues so what you are experiencing is an implementation issue.
As Beatrix asked, please define “crashing”. There’s an exception that you’re not handling and then there’s the application goes poof and the app just goes away with zero information given to you. The former is easy to deal with the latter is not.
The program just locks up and in the debugger there is no information on the error location at all just the normal variable and object information. If I remove the DoEvents statement the errors stop, so I feel it is the most likely cause. Your are correct that I don’t have any exception handling in that routing and I’m putting that in now if just to have a better idea of the cause of it.
You can also use system.debuglog (http://documentation.xojo.com/index.php/System.DebugLog) to write log message to the console.
On windows you can view these messages with debugview that I mentioned to you earlier today.
Good luck in finding the bug. 
Thanks Dirk, another good idea … I’ll have a go at it.
When using a thread I create it can still see all my global APP level properties, right? Or do I need to create special properties just for that thread and set them myself before firing the Run method?
As long as you aren’t changing any UI elements you can use the global app properties all you want.
But when using real threads, you need first to lock the access to the resource to avoid conflicts. It’s done in Xojo usually with CriticalSections
Since xojo uses cooperative threading, this usually isn’t necessary.
While Xojo uses Fibers instead of Threads, I believe there is a better motivation to have the functionality in the language beyond having just a page in manual; and it should to be used for the current practices, even if currently it’s not really necessary due to the fact of the current rendered code just use one core, with time slicing, and no real concurrent access. If you don’t produce correct code, when they finally fix the system, it will break your code; and fixing it could be a bit hard after. Making the code ready from the start is a good policy. I even believe Xojo should study a way to introduce a new class called Fibers, that act like the current one, slicing the time of the main thread, without the unnecessary sync functionality overhead (just enter()/release() to hold context in the current Fiber beyond its time slice), and it could even being UI aware and able to access it directly. People currently should migrate to it. Then, later, reintroduce threads, asyncs, and etc to enable full use of the CPU cores and all the advanced stuff they are afraid to put in their users hands due to complexities of the inevitable future use of them.
Thanks to all for the feedback!
I need to make sure I have only one instance of my thread running at a time and though I could use the Critical Section much the same way programs use the Mutex to keep only one copy of a program running byy use the TryEnter method. Is this reasonable or is there a better more acceptable way of preventing the same thread.Run from being call multiple times and throwing an exception error.
I believe this were changed in the past and Xojo no longer uses fibers, but threads.
Nope. They just call Fibers as Threads. Fibers are like threads, but use co-operative multitasking subject to some fails due to be software dependent for switching contexts and being busy in some loop for a long time, never releasing time to others; while threads use preemptive multitasking, switching contexts disregarding cooperative code, and even using different CPU cores for each thread. Threads are designed to extract more real parallel processing power from the CPU, Fibers are designed just to simulate parallel processing slicing time of just one core in one thread. Xojo uses fibers and calls them Cooperative Threads. Threads are something for the future. I was expecting them for the new frameworks and compilers, LLVM based. But it seems not possible right now because they are completely full of work just updating everything for 64 bit and new CPUs (Intel/ARM).