Multithreading - User Interface

I need to write a multithreaded application. The main application thread is going to handle all the user interface. The worker thread is going to perform all the background tasks. It is a going to be a long process and there is a need to display to the user a choice to let the process continue or abort in-between. Also, a user needs to be informed as to what stage is the worker thread in. For example, if the worker thread is copying files, a message needs to be displayed that says "Now copying files...". When the status changes to something else, a new message needs to be displayed. I can handle the worker thread. The question is : In the user interface thread, what kind of dialog box/notification should I use so as to handle this situation ? The user interface is NOT written using the MFC classes. I need to use only win32 functions to handle all that. Please help.
Who is Participating?
NickRepinConnect With a Mentor Commented:
There is simple enougth method to display current state of background thread. Just use shared memory for bkgnd and user interface threads. For example:

// Shared variable, do not use  __thread keyword
char msg[120]="";

//Bkgnd thread
void BkgndThread(void)
   // Starting;
   strcpy(msg,"Thread started");
   // CopyFile
   strcpy(msg,"Now copying files...");
   //... etc.
void UserInterfaceThread()
   CreateTimer(1,5000)   // For example, update status in 5 sec
LRESULT WindowProc(...)
   case WM_TIMER:

Of course, it may cause problems, ie SetText may be invoking while strcpy() performing string copying. To avoid this you can use EnterCriticalSection/LeaveCriticalSection before/after 'dangerous' code.

Also you can check 'exit flag' in bkgnd thread from time to time.

Or, use CreateEvent() & WaitForSingleObject() to perform all this task. I.e., bkgnd thread copies status string to msg and sets event to signaled state. User-interface thread waits for this event and displays status string when event occures.
I think you should rather send messages from the thread to your main window than updating the control bar on a timer base. This will be more effective and flexible.
psapraAuthor Commented:
'Markusk' - I'd like to get some more details on sending messages between the worker thread and main thread.

NickRepin - I was thinking along the same lines as you had suggested. The only difference was that instead of a string message, I was deciding on a set of enumerated messages. I could declare a global volatile variable. The worker thread updates the value of this global variable. In the main thread, I can switch on the global variable's value and display the appropriate message. My question still remains - What call do I use to display a dialog box that does not wait for a user input like a modal dialog box ? Also this should be capable of handling a user input if 'Cancel' is clicked. How do I handle the creation & destruction of this dialog box ?

You should use WinAPI's CreateDialog() to display a modeless dialog instead of DialogBox(). To destroy a modeless dialog box use  DestroyWindow() function.

If your background thread uses linear code model (i.e. not messages handling) then you should call CreateDialog() in main or auxiliary (third) thread.
1. Create background thread
2..Create modeless dialog and store dialog's handle returned by CreateDialog() to thread-shared variable.
Now the main thread may continue processing of other job.

if user presses "Cancel" then dialog box procedure must use TerminateThread()/'abort-flag'/other to terminate background thread and DestroyWindow() to close itself .

While working, background thread may post via PostMessage() (SendMessage()) the enumerated messages directly to dialog box procedure to display its current status.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.