Messages not being processed
Bruce -- bmiller@geographix.com
Monday, November 11, 1996
Environment : VC++4.1, NT 4.0
I have a modal dialog which launches a miniframe window.
This window contains a toolbar, which is not receiving
OnUpdate messages. I was told that the modal dialog
is blocking the main window's message pump.
Is there a way to get around this, without removing
the modal dialog?
bruce miller
bmiller@geographix.com
SachinX Keskar -- SachinX_Keskar@ccm.jf.intel.com
Tuesday, November 12, 1996
Text item:
If the Dialog is blocking messages, check if the message is for the dialog.
There is a API for checking this.
See IsDialogMessage.
Environment : VC++4.1, NT 4.0
I have a modal dialog which launches a miniframe window.
This window contains a toolbar, which is not receiving
OnUpdate messages. I was told that the modal dialog
is blocking the main window's message pump.
Is there a way to get around this, without removing
the modal dialog?
bruce miller
bmiller@geographix.com
Text item: External Message Header
The following mail header is for administrative use
and may be ignored unless there are problems.
***IF THERE ARE PROBLEMS SAVE THESE HEADERS***.
Reply-To: mfc-l@netcom.com
Precedence: bulk
Errors-To: owner-mfc-l@majordomo.netcom.com
Sender: owner-mfc-l@majordomo.netcom.com
Ioan Berbece -- berbece@itls.com
Tuesday, November 12, 1996
[Mini-digest: 4 responses]
The same problem arises when you try to put the time in a status bar
and after that you launch up a modal dialog box. Because the modal
dialog box has its own message loop, the application's OnIdle() method
doesn't get called and the time is not updated.
The resolution:
1) set a timer before activating the modal dialog box (let's say 1
second)
2)in the timer's function force the application's OnIdle().
Ex.
....
UINT nTimID = SetTimer(TIMER_ID, nSeconds * 1000, TimerProc);
ModalDlg modDlg;
modDlg.DoModal();
VERIFY(KillTimer(nTimID));
....
void CALLBACK EXPORT TimerProc(HWND, UINT, UINT, DWORD)
{
AfxGetApp()->OnIdle(0);
}
Ioan Berbece,
Software Engineer,
InterTrans Logistics Solutions
-----From: Dave Kolb
That is what a modal dialog is SUPPOSED to do - i.e. block the main
message loop. Look into "modeless" dialogs if you want main message loop
processing to continue.
Dave Kolb
PC Research and Development
SAS Institute Inc.
919-677-8000 x6827
-----From: "GoroKhM1"
These articles may help you:
Q117500 Using Accelerators with an MFC Modeless Dialog Box
Q100770 Accelerator Keys When Modal Dialog Box Main Window
MarkG@usa.net
-----From: David Little
Why not start the mainframe app in its own thread using CreateProcess? I think your suspicion is accurate....
Marty Fried -- mfried@linex.com
Tuesday, November 12, 1996
I believe that with VC4.1, all dialogs are non-modal, and are
handled by the framework - assuming you are using CDialogs, and
not SDK direct.
Don't the toolbars send the messages to the parent window? Also,
there is a tech note (31) about required ID ranges.
Hope this is helpful.
Marty Fried
Marin County, Calif
-------------------
At 06:02 PM 11/11/96 -0700, Miller, Bruce wrote:
>
>Environment : VC++4.1, NT 4.0
>
>I have a modal dialog which launches a miniframe window.
>This window contains a toolbar, which is not receiving
>OnUpdate messages. I was told that the modal dialog
>is blocking the main window's message pump.
>
>Is there a way to get around this, without removing
>the modal dialog?
>
>bruce miller
>bmiller@geographix.com
>
>
Anders N Weinstein -- andersw+@pitt.edu
Wednesday, November 13, 1996
This doesn't work, does it? The timer messages go to the window that set
it and not dispatched during the modal dialog because it is disabled.
You could set a timer in the *dialog* window to do this in it's
OnInitDialog.
On Tue, 12 Nov 1996 berbece@itls.com wrote:
> The same problem arises when you try to put the time in a status bar
> and after that you launch up a modal dialog box. Because the modal
> dialog box has its own message loop, the application's OnIdle() method
> doesn't get called and the time is not updated.
> The resolution:
> 1) set a timer before activating the modal dialog box (let's say 1
> second)
> 2)in the timer's function force the application's OnIdle().
>
> Ex.
> ....
> UINT nTimID = SetTimer(TIMER_ID, nSeconds * 1000, TimerProc);
> ModalDlg modDlg;
> modDlg.DoModal();
> VERIFY(KillTimer(nTimID));
> ....
> void CALLBACK EXPORT TimerProc(HWND, UINT, UINT, DWORD)
> {
> AfxGetApp()->OnIdle(0);
> }
Ioan Berbece -- berbece@itls.com
Friday, November 15, 1996
QUOTED DOCUMENTATION
UINT SetTimer( UINT nIDEvent, UINT nElapse, void (CALLBACK EXPORT* =
lpfnTimer)(HWND, UINT, UINT, DWORD) );
=20
Return Value
The timer identifier of the new timer if the function is successful. An =
application passes this value to the KillTimer member function to kill =
the timer. Nonzero if successful; otherwise 0.
Parameters
nIDEvent Specifies a nonzero timer identifier.
nElapse Specifies the time-out value, in milliseconds.
lpfnTimer Specifies the address of the application-supplied TimerProc =
callback function that processes the WM_TIMER messages. If this =
parameter is NULL, the WM_TIMER messages are placed in the application's =
message queue and handled by the CWnd object.
Remarks
Installs a system timer. A time-out value is specified, and every time a =
time-out occurs, the system posts a WM_TIMER message to the installing =
application's message queue or passes the message to an =
application-defined TimerProc callback function.=20
The lpfnTimer callback function need not be named TimerProc, but it must =
be defined as follows and return 0.
=20
void CALLBACK EXPORT TimerProc(
HWND hWnd, //handle of CWnd that called SetTimer
UINT nMsg, //WM_TIMER
UINT nIDEvent //timer identification
DWORD dwTime //system time
);
=20
Timers are a limited global resource; therefore it is important that an =
application check the value returned by the SetTimer member function to =
verify that a timer is actually available.
QUOTED DOCUMENTATION
Answer: YES it does work! Can you answer why?
----------
From: Anders N Weinstein
Sent: Wednesday, November 13, 1996 2:07 PM
To: mfc-l@netcom.com
Subject: Re: Messages not being processed
This doesn't work, does it? The timer messages go to the window that set
it and not dispatched during the modal dialog because it is disabled.
You could set a timer in the *dialog* window to do this in it's
OnInitDialog.=20
On Tue, 12 Nov 1996 berbece@itls.com wrote:
> The same problem arises when you try to put the time in a status bar=20
> and after that you launch up a modal dialog box. Because the modal=20
> dialog box has its own message loop, the application's OnIdle() method =
> doesn't get called and the time is not updated.
> The resolution:
> 1) set a timer before activating the modal dialog box (let's say 1=20
> second)
> 2)in the timer's function force the application's OnIdle().
>=20
> Ex.
> ....
> UINT nTimID =3D SetTimer(TIMER_ID, nSeconds * 1000, TimerProc);
> ModalDlg modDlg;
> modDlg.DoModal();
> VERIFY(KillTimer(nTimID));
> ....
> void CALLBACK EXPORT TimerProc(HWND, UINT, UINT, DWORD)
> {
> AfxGetApp()->OnIdle(0);
> }
Anders N Weinstein -- andersw+@pitt.edu
Monday, November 18, 1996
On Fri, 15 Nov 1996, Ioan Berbece wrote in response to my mistaken q:
AW: This doesn't work, does it? The timer messages go to the window that
AW: it and not dispatched during the modal dialog because it is disabled.
> QUOTED DOCUMENTATION
> UINT SetTimer( UINT nIDEvent, UINT nElapse, void (CALLBACK EXPORT* =
....
> Answer: YES it does work! Can you answer why?
I sent a retraction of my query but evidently not in time. However the
relevant documentation for *my* misunderstanding would be in EnableWindow.
Having observed that my status bar clock did not update during modal
dialogs, I erroneously inferred that timer events were not dispatched to
disabled windows. Now I understand it is due rather to idle processing not
being done. Apologies again.
BTW: is there any way to force an update of a single status bar pane
programmatically (*without* going through the idle-time update UI
mechanism)?
| Вернуться в корень Архива
|