I don’t even know if this is possible… here’s basically what I want:
Something similar to the thread.run event, but it’s a method. Instead of:
thread.run
I want to be able to pass arguments to a method, and have it return the processed declared variable… which did all of its processing within a thread. Something like:
myReturn = thread.run(myArgument) 'even byRef returns would be fine
Is something like this even possible? I’m trying to find solutions to my issues, one of them is incorporating more use of threads, and staying away from loops that use the app.doEvents while a process is being completed.
sure it’s possible. Have a method which takes a delegate, creates a new thread, puts delegate in thread property, call run method. In run event of thread, use delegate property to call method.
I have very little experience working with delegates, and using the invoke to call them. It’s something I will definitely look into, if this will solve my problem. Appreciate the quick response, Christian!
You really need to embrace asynchronous, event driven programming. Which is really what Christian is proposing anyway. Even with delegates, it won’t run synchronously. You could make a thread run synchronously by using a Semaphore, but then what’s the point of using a thread? You’re going to block the UI just as if you’d not used a thread in the first place.
[quote=98481:@Eric Brown]I don’t even know if this is possible… here’s basically what I want:
Something similar to the thread.run event, but it’s a method. Instead of:
thread.run
I want to be able to pass arguments to a method, and have it return the processed declared variable… which did all of its processing within a thread. Something like:
myReturn = thread.run(myArgument) 'even byRef returns would be fine
Is something like this even possible? I’m trying to find solutions to my issues, one of them is incorporating more use of threads, and staying away from loops that use the app.doEvents while a process is being completed.[/quote]
I think what you really want is to subclass a thread and write a constructor for it
The constructor takes all your values that you’re trying to have the thread “compute” with (maybe a "Context that you canteen just add properties to without having to change the thread constructor all the time)
The other thing it takes is an “address of” callback to let you know when its done (well maybe weak address of)
Then in your current code you create an instance of the thread & set it up and tell it to run
When its done it calls your code back and you can grab the results from perhaps some public properties on it
A similar technique is to subclass a thread, but then put the thread subclass instance on a window. Add some Events to the subclass that can be used for communication to the owner window. I’ve used each and can recommend them both.
I agree with Michael, it can be useful to have an instance of the subclassed thread class as a property on your window. You can then check its properties (with a timer for example) and act on the data in them.
My example is where you can simply create a thread in code and pass it the address of a delegate method:
dim dt as delegating_thread = new delegating_thread(AddressOf long_string_append)
The delegate is defined in the delegating_thread subclass and requires an instance of delegating_thread as a parameter.
This allows the passed method to refer to the thread.