[RESOLVED] Quick Question

[thud]

I have a dll that outputs text and uses threads however it is not instant.. it takes about a half a second to one full second.

my code uses the value too soon (before it is set)

What I do is:

set ANSWER = nothing

run the file through the DLL

then use the answer

The answer is being used to soon.

I've tried several things such as:

set ANSWER = nothing
run the file through DLL

do until not answer = nothing
loop

then use answer

but this freezes the program.

how can i wait until "answer" has a value before using it?

[jmcilhinney]

Please use descriptive thread titles in future. If everyone who had a quick question used that thread title then thread titles would be completely useless.

As to your question, it really depends on the specifics of the code. You would most likely have the worker thread raise an event or else invoke a callback, which is a delegate that you pass to it when you start it. You should NOT have the main thread actively waiting for a value that will not be available at a prescribed time.

[Shaggy Hiker]

You make it sound like the DLL has a function that runs on a thread and eventually supplies the answer. That may or may not be what you meant. If the main thread starts a thread that calls the DLL function, then the UI thread would have control of this worker thread. If the worker thread is spawned in the DLL...well, that would have a different solution.

The basic issue is that the UI thread needs to wait for the value to be filled in. If you block while waiting for that (as your loop would effectively do, though at the cost of using 100% of the CPU), the UI freezes, as you noted. One alternative that would keep the UI from freezing, but would otherwise be a totally horrid solution, would be to add a DoEvents into your loop. The UI would be responsive, because the loop wouldn't totally block messages from getting processed, but the CPU would be pegged throughout the wait, which is far from ideal.

The best solution that I can see, if the worker thread is entirely within the DLL, would be to call the DLL function from a worker thread in the main program. By doing that, you could start this worker thread and let it raise an event when the DLL function finally returns an answer. This would leave the UI thread available for whatever. Of course, if the worker thread you mentioned originally is not within the DLL, then you are already doing what I suggested, and just need the thread to raise an event when completed.

I'm going to quit there. I had written some other stuff about polling in the worker thread that is waiting for an answer, but I think I was making too many assumptions.