Getting Back to the Message Loop 1

[LyMc]

This one should be easy for you'all out there - I know, I've said that before, but on this one I mean it.

I have a windows app that presents a menu interface. When you push the right buttons and make the right selections, it then goes off and processes a file. Depending on the file size, it might take it some time. In order to keep the user from giving up in dispair, I've placed a dialog on the screen with a progress bar and a Cancel button to allow them to kill the process and gain control back if it appears to take too long.

The problem is, the Cancel button doesn't work. I don't see (in the dialog handler) the message come through, and I'm sure it's because the routine that is running has taken control away from the message loop completely while it's doing its thing. I periodicaly call a function that updates the progress bar, but it never gets back to the loop, so the Cancel never gets read or dispatched.

So, the question is, what do I need to add (for example, into the progress bar update function) to assure that messages that occur during the processing get handled? Is there a simple call that will cause the message loop to get exercised and then return when it's empty? Do I actually have to build another message loop into the progress bar function?

Here is the code of the message loop as it exists now, for reference (hDlgModeless is the dialog's window handle):

   while (GetMessage (&msg, NULL, 0, 0)) {
      if (hDlgModeless == NULL || !IsDialogMessage (hDlgModeless, &msg)) {
         if (!TranslateAccelerator (msg.hwnd, hAccelTable, &msg)) {
            TranslateMessage (&msg);
            DispatchMessage (&msg);
         }
      }
   }

 

[Cagliostro]

if you want to catch buttons messages, you should catch WM_COMMAND. The parameter wParam will equal to ID of cutton, I think is IDCANCEL.

Ion Filipski

 

[LyMc]

Ion,

That's exactly where I tried to catch it. I put a breakpoint on the WM_COMMAND case statement in the hDlgModeless dialog process (the cancel button is the only editable control in the dialog), and it did not trigger when I pressed the Cancel button.

 

[lorenzociripenso]

I had something similar in my application. I solved assigning the data processing to a working thread. Don't be scared now.

You can start your thread in your application with:

void CSoccerVisionDlg::OnButtonstart()
{
AfxBeginThread(YourThread, this); // start thread
}

Implement the data processing in the thread function which is declared global like:

UINT GameThread(LPVOID pParam)
{

}

The thread keeps the GUI still working. isn't that nice? tell me if it works...

 

[lorenzociripenso]

one more thing...

you should declare your thread in the same file in which you call it and before!! you call it.

you should substitute GameThread or YourThread in my examples with the name of your thread.

 

[LazyMe]

You can also check for the WM_COMMAND messages while going through the file with PeekMessage() every once in a while (if processing is done in a loop, this would be very easy...).

The one and only reason that you don't get to see the WM_COMMAND message in your messageloop is simply because you're not in the loop while processing the file....

Greetings,
Rick

 

[LyMc]

OK - I took LazyMe's approach and added to the progress bar setting function the code:

[code
while (PeekMessage (&msg, hDlgModeless, 0, 0, PM_REMOVE)) // Take a look for any messages that may be in the queue.
IsDialogMessage (hDlgModeless, &msg);
[/code]

And it works like a charm. The Cancel request goes through and the progress bar gets destroyed. Had to also add code to kill the ongoing process - silly me; I forgot the code was driving the window, not vice versa. Anyway, all's well. Thanks agin, guys.