I have opened the current LR to check on the current syntax and operation for threads.
I see an event named “Run”. The summary says:
The Run method has been called. The threaded code is placed in this event handler. Methods called from here also run in the thread.
Then the UG in “User Guide Framework Threading:Threading” says:
To start a thread you call its Run method, which calls the code in the Run event handler.
But the LR says nothing about a Run method, only a Run event handler. Where is this “Run method”?
Then I see under the LR Thread.Start method:
Starts the thread’s Run event handler.
Is Run really Start now?
Further details lacking: Do you have to “new” a thread? Does the thread exist before Run is executed? When you Run a thread, do you also have to Start it? Can you write to thread properties before it runs?
I have my own thread class, a subclass of what Xojo provides. I instantiate it with ‘new’.
You put your code in the Run event handler. It starts running when you do yourThread.Start().
Edit: if you have several threads of different purposes with different code for the thread, you can also have your own method that you attach to the Run event with Addhandler. But remember to use RemoveHandler if your thread quits before the app.
I use Xojo 2018 for most things at the moment.
API2 may have changed things a bit.
In API1…
If you add a thread to a window at design time, it is ‘newed’ when the window is.
The object has a method called Run
You need to add an event handler to the object… there is only one you can add, and it is also called ‘Run’
In that event you add code or a call to a method.
Before you call the run method, you should check to make sure the thread is not already running.
You do that by checking the .state property
eg
if Thread1.state <> 0 then //if it is not running
//start a timer here?
thread1.run
end if
You might have a timer on the window, running multiple times, watching the thread, and maybe updating a control for progress.
It will examine the state property, and might do something when the thread completes.
eg
if thread1.state = thread.NotRunning then
me.mode= timer.ModeOff
//do mopup
Without much thinking, I started off with an independent Thread class. In my application, it really does make sense to attach it to a window. From what you have written, it sounds like the thread exists, then, as soon as the parent window is open. Then, I should be able to pass variables into it before Start.
This thread, which is a text message parser, outputs a response string which is displayed in one or more windows. This response message will only be valid after the thread has reached its end. I will probably write that response and a status flag to properties in App and use timers in the windows to check for the status flag so that the windows can be updated.
Uggh, I thought that threads had variables that could be written to from the outside. Does not appear so (maybe there was in past thread lives). Will have to use a transfer buffer, elsewhere. But, that can be done without violating the wall between the GUI and the thread, I think.
Make a new class called “MyThread” (or simialr) with a superclass of Thread.
Then you can add properties, methods, etc. to the MyThread class. You can put an instance of this on your Window (or create a new one in code, etc.)
In the majority of cases I’d agree with you, but this one is actually for the better imo. It used to confuse the heck out of me (as it confused the OP) that you would call an event. The Run event firing as a result of calling Thread.Start makes much more intuitive sense.
Well, according to the title, OP was confused mainly by the Documentation, “where is the Run method?” that confusion is caused by the name change. And it is going to happen to a LOT of people, find old documentation or tutorials that will not work with API2 new proyects and they are going to be as confused.
