Passing parameters to new thread

I’ve already mentioned in another post that I’m trying to update some old RealBasic code to XOJO. The main impediment at this point is communicating between a thread and the user interface. The thread in question does some heavy duty number crunching, and needs to post status data to an edit field in the main window every so often. In RB, this was not an issue; a thread could access UI controls. Not so for XOJO. I’ve come up with a simple but ugly bit of code to resolve the output issue, but I still need to send several parameters to the thread when it launches. The way it used to work, the thread code would just read the data out of several text fields in the main window. However, this is no longer possible. I can have the main code read these fields, put the data into global properties, and have the code in the thread read it from there. However, transferring data via globals is stone age programming. There must be a cleaner way to do this, but I can’t see any simpler way at the moments

Ugh. Don’t use global variables. My preferred method for this situation is a notification system which brings the necessary information to the window and sets a property. Then I use CallDelegateOnMainThreadMBS to change the window. This call from the MBS plugin allowed me to do away with most of the spaghetti code that I used before with threads and timers and whatnot.

Hi Beatrix,
Thanks for your reply. As I mentioned I don’t like the idea of using globals to pass data, but didn’t see any simple alternative. By MBS (MonkeyBread Software?), I assume you mean that it’s necessary to resort to 3rd party software in order to have some semblance of clean code? So, it doesn’t appear that XOJO has bothered to provide any kind of clean built-in data interface to threads? Oh dear!

Subclass the thread and create the properties you need. Before running the thread, fill in those properties.

As for updating the ui, take a look at the task example that comes with Xojo.

Subclass from Thread and add a constructor with all the necessary stuff as parameters.

Okay, thanks everyone.

I have to say, I was hoping that with 7 years of improving technology, this would be an easy migration rather than finding that nothing works anymore, and the developer now has to create a lot of interface code that, at one time, was automatic.

I’ve already looked at the “Task” example, and I’ve come up with a much simpler way to update the UI. It’s ugly, but it’s extremely simple and it works. And having it work is of primary importance at the moment.

As for passing parameters to the thread, I have to say that I’m amazed that the only way to do it is by subclassing the thread. I’ll look at doing this later, but for now, it appears that globals are going to be the quickest way to get this up and running. If we get the performance that we’re hoping for, then we can go back later and jump through all of the hoops. If not, we’ll leave it as an RB 2009 project, and reevaluate our options at some point in the future.

It wasn’t “automatic”. The Xojo engineers had been recommending against doing what you were doing for years. The only difference now is, they enforce it. We’ve all had to go through it and it’s really not that big a deal.

Creating a Thread subclass and adding properties to it is just as quick, and is ultimately safer than using globals.

Actually Apple enforced it.

As for updating the UI from a thread, I switched to using CallLater. I find that a lot easier and cleaner.

(Actually, I’m using a slightly updated version of Karen’s KAtkoSoft SingleActionTimer Class because Xojo’s CallLater causes IteratorExceptions on CancelCalls if you’re hammering it really hard)

Actually, this is probably a perfectly legitimate use of globals, since the global property simply reflects the contents of the edit field in the UI.

As for passing parameters to the thread, that is a bit different, and I will try to clean that up as much as possible. But, at the moment my primary interest is what kind of performance improvement we might get in 64 bit mode. If we’re happy with that, then I don’t mind spending the time to sort out a clean way to pass parameters.

I don’t understand your thinking. Subclassing a thread and passing parameters to a constructor is dead simple. Actually easier than using globals. If you don’t want to use a constructor, create a Run method that takes the extra parameters. Save them to the variables your thread uses and then call the normal Run method. There are many clean ways to do this that require very little effort.

[quote=265444:@Robert Weaver]Hi Beatrix,
Thanks for your reply. As I mentioned I don’t like the idea of using globals to pass data, but didn’t see any simple alternative. By MBS (MonkeyBread Software?), I assume you mean that it’s necessary to resort to 3rd party software in order to have some semblance of clean code? So, it doesn’t appear that XOJO has bothered to provide any kind of clean built-in data interface to threads? Oh dear![/quote]

No need for globals or convoluted methods. If you want to use a plain thread, use properties of the window or the ContainerControl onto which you dragged the thread. For instance threadParam1 as Integer, threadParam2 as string, etc. which the thread will have access to.

Tim Hare’s suggestion is preferable if you want a more generalized method. On a thread subclass, you can for instance create Param1, Param2, Param3, and add a myRun() method that takes those parameters, so you can pass them at the same time you run.

You can then do Thread1.myRun(123,456,789)

When I mentioned globals, I really meant properties of the window where the thread runs. I think this is what Michel is suggesting.
Actually, I didn’t think globals in the classical sense were even possible.
As for getting output data from the thread displayed in the window, I’ll probably set up a simple timer. I’ll have a look at the task class at some point, but for now, I’d rather work with things I’m familiar with.

When I do these kind of migrations, I tend to get in a panic and then do whatever I can think of to quickly get things up and running, and then clean up the mess later. However, after taking a deep breath, and having another look, passing the data back and forth doesn’t appear to be much of an issue. Thanks everyone for the advice.

Found this discussion today while looking for a solutions to a similar problem. I am also moving old RB code into Xojo and get stumped by the lack of simplicity. Neither the ‘Task’ and Timer options seem applicable to my project and the help in Xojo isn’t nearly as good as in the good old RB IDE. After all these years I still dread opening Xojo and I still use RB 2009 whenever possible. I realize this sounds like a rant but it’s more that I have come to realize Xojo is not a replacement or evolution of RB. It’s a new behemoth that just isn’t as useful. Powerful perhaps, but not the joyful simple dev tool that RB was.

Peter, I was frustrated at the time, but once I got the hang of using a timer to communicate between the thread and the user interface, everything fell into place. There was a bit of a learning curve, but it wasn’t really that bad. The newer Xojo versions offer a lot of improvements over RB, so I would encourage you to spend the time to upgrade your application.