How to process window messages during long operations.

I have an app which recursively searches directories for arbitrary file types. During this extensive search, the app will no longer respond. I would like to be able to continue processing window messages while the process is executing (executes within a child window). How can I accomplish this? Does this require spawning another thread for the search process?
Who is Participating?
jkrConnect With a Mentor Commented:
>>I would like to be able to continue processing window
>>messages while the process is executing (executes within
>>a child window).
>>Does this require spawning another thread for the search

Spawning another thread would not be a too bad idea. But, simply 'draining the message queue from time to time during a lengthy operation is not too difficult:

void DrainMessageQueue()
  MSG msg;

    while   (   PeekMessage (   &msg,   NULL,   0,  0,  PM_REMOVE)
                DispatchMessage     (   &msg);

So, when you're e.g. running through a loop, you could just

while ( whatever)

  // do processing

This will ensure that your GUI doesn't 'freeze'
Any operation that takes a long time to run will block your app from processing Windows messages.  When this happens, the app will be unresponsive.

To work around this, start your search in a thread of its own.  This is exactly the kind of situation where threads make sense.
sgraves66Author Commented:
Both answers are correct. I'll give the points to whomever can answer this, since it started after I created a worker thread. I have a CDialog-derived class which I use to display the progress of the search. Now, the app processes all messages. I need the dialog to be a child of the window running the process, the dialog shouldn't move,  and it shouldn't block any other child windows within the MDI main window. The child window running the process should not respond to any window message while the search is still active.

Increasing points.
Get your problem seen by more experts

Be seen. Boost your question’s priority for more expert views and faster solutions

You could do that using 'AttachThreadInput()':

Windows created in different threads typically process input independently of each other. That is, they have their own input states (focus, active, capture windows, key state, queue status, and so on), and they are not synchronized with the input processing of other threads. By using the AttachThreadInput function, a thread can attach its input processing to another thread. This also allows threads to share their input states, so they can call the SetFocus function to set the keyboard focus to a window of a different thread. This also allows threads to get key-state information. These capabilities are not generally possible.

sgraves66Author Commented:
Ok. I'm using a doc/view MDI setup. I've created a CWinThread-derived class and added some extra functionality. Where would I instantiate the thread class in order to have it manage the view associated with the document?

a) "should not respond to any window message"
this implies that it isn't repainterd correctly. Is this what you want?

b) Keep all access to CDocument / CView in the main thread. The Doc/View architecture is not suited for multithreading.

MFC can handle "normal" window/dialog multithreading. but as soon as a CDocument gets involved, you're out for trouble.

Do all UI updates in the main thread. Design a memory  area where the threads exchange data. Use PostMessage from the worker to the main thread to inform the main thread it should update the UI.

To keep the dialog fixed at size & position (I wonder if I would like that), just override the OnSize/OnMove handler, and return immediately while search is active.

What do you mean with "should not block aby window of the main thread"  ??
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.