Thread Vs. State Machine Vs. ???

[Mark Newman]

I'm porting a VB6 app over to PB and I have a question about lengthy processes. This
app's main process can take up to 45 minutes, so it would be bad form to lock up the
PC while the app runs. I'm using a modeless DDT dialog for the UI, so I'm wondering
what's the best way to keep the UI responsive while the main process executes. As I
see it there are 3 choices:

1) Create a thread for the process. There aren't any sync or data sharing issues here.

2) Create a state machine that's driven by a timer. I've done this many times before,
but this process is rather complicated so a state machine could get messy.

3) Sprinkle DIALOG DOEVENTS throughout the process code. Would probably work, but I'm
not keen on having billions of these calls cluttering up the process code.

Anyone have any comments? I'm leaning towards #1 myself but I've never done threads in
PB before, though it looks pretty easy.

Thanks!

------------------
Mark Newman

[Lance Edmonds]

Personally, I go for a separate "worker" thread - especially as no data sharing is involved, it should be very easy to implement.



------------------
Lance
PowerBASIC Support
mailto:[email protected][email protected]</A>

[Dominic Mitchell]

In SDK style coding the best way to implement a UI that remains very
responsive when a lot of non UI processing is involved is to use
MsgWaitForMultipleObjects. The application can then be single threaded
or multithreaded with worker threads.

------------------
Dominic Mitchell

[Mark Newman]

Hmmm, I'm a bit familiar with WaitForSingleObject, but not with this one.
I'll have to read up a bit and see if I can apply it to a DDT app.

Thanks!

------------------
Mark Newman