Re: Thread Deadlock

From: Mihajlo Cvetanovic (mac_at_RnEeMtOsVeEt.co.yu)
Date: 09/14/04 

Date: Tue, 14 Sep 2004 11:18:18 +0200

rob wrote:
> Thanks for your input. I have a question, though. How can an app update
> itself when an event handler of this app creates a modal dialog? The app
> does not get out of the event handler until the dialog is closed. So how
> does the message loop in the modal dialog help the app to be updated? In my
> thread I can't directly call a function in the main app (I am not sending
> messages but do a direct call). So how can a function in the main app be
> executed when the app is stuck in the event handler that popped up the modal
> dialog?

1. Message handling

Every window has a function that gets called when a message needs to be
dispatched to it. This function is registered to a window, and this is
hidden from you in MFC, but create non-MFC project and see what wizard
gave you. This function is called from a Message Pump. All message pumps
(including those in both MFC and non-MFC projects, dialog boxes, even in
message boxes (created with [Afx]MessageBox) look pretty much like this:

while( (bRet = GetMessage( &msg, NULL, 0, 0 )) > 0)
{
   TranslateMessage(&msg);
   DispatchMessage(&msg);
}

So, message handler for one window (dialog) gets called from message
handler of another window (main window). While in dialog, message pump
can call main window's message handler just as well. Only thing to
remember is that message pump must always be "alive", which means that
you can't wait too long in one message handler and not do something that
creates another message pump.

2. Call Stack of a Thread

When debugging observe the Call Stack. You'll see a number of functions
one on top of another. It doesn't matter what are those functions, or
whose classes are they belonging to. What matters is that every thread
has its own call stack, totally independent of stacks of other threads.
To put it another way: threads have context, classes don't have context.
It doesn't matter if that class is derived from CWinApp, or whatever.

HTH

Relevant Pages

  • Re: Cant Move Overlapped Window to Front
    ... I know that my message pump is working -- when I ... my OnPaint() handler executes and I ... can see the updates in the portion of my window not obscured by other ...
    (microsoft.public.vc.mfc)
  • Re: Batch file and MFC (Properly Terminating Application)
    ... to close a program except at the user's request, which means the handler is a direct ... descendant of the top-level message pump, I never worry about cases like this. ... the changes the user thought had been made--because the app closed without ... user clicks on Cancel button and application exits. ...
    (microsoft.public.vc.mfc)
  • Re: Batch file and MFC (Properly Terminating Application)
    ... running any secondary modal loop. ... don't write an OnCancel handler, ... the changes the user thought had been made--because the app closed without ... user clicks on Cancel button and application exits. ...
    (microsoft.public.vc.mfc)
  • Re: Losing data in controls (and arrays) during unhandled exceptions.
    ... Errors will "bubble up" through the routines until an active error handler ... So if the first routine has a handler, you can deal with it there. ... I guess having to hit the 'Reset' button should have been ... worksheet when the app is shut down, ...
    (microsoft.public.excel.programming)
  • Re: wm_paint not enough?
    ... > I am developing an MFC Dialog based app. ... a disabled edit control to display some graphic output. ... With the Wm_Paint handler in place, ... dialog window, and the output is correctly restored. ...
    (microsoft.public.vc.mfc)