Re: capturing windows messages to parent dialog box
"Scott McPhillips [MVP]" wrote:
"Srivatsan "Vat" Raghavan" <Srivatsan "Vat"
Raghavan@discussions.microsoft.com> wrote
the problem is that both my CDialog app and the Cmessagebox i'm using are
modal dialog boxes, and it appears that if you popup a modal dialog box
the
parent window is neither enabled (fine) nor can it receive windows
messages
(which isn't) so i don't process the packet until the modal box either
shuts
down via timeout, or cause the user clicked ok, which is of course wrong.
the packet processing happens in a thread i spawn on startup, so I'd have
thought it wouldn't be blocked, but it appears to be.
Parent windows *do* continue to process windows messages while a modal
dialog is active. Perhaps you are using some message that is misinterpreted
as a user interaction. The best choice for user-defined messages is WM_APP
+ n.
Furthermore, if your secondary thread becomes blocked due to a modal dialog
in the main thread then you have a design problem. One common mistake is to
put a never-ending loop in the main thread: As long as it is looping no
messages will be processed. Another common mistake is to use SendMessage
from the secondary thread.
the thread handler function looks like this, actually ->
UINT PacketProcessThread(void *ptr)
{
CMyDlg *pDlg = (CFMainUIDlg*)ptr;
pDlg->m_bThreadEnd = false;
while(pDlg->m_bProcessPackets)
{
Sleep(100);
//Process packets including receive and send out
pDlg->ProcessPackets();
}
pDlg->m_bThreadEnd = true;
return 0;
}
then CMyDlg::ProcessPackets just does a switch-case on packet type, it's a
exceedingly simple protocol, but then i didn't write it, and i'm sure there
are issues w/ the methodology, but then i didn't write it.
i should clarify what i meant by 'message'. sorry i mixed up windows
messages and our custom packet protocol.
my idea was that the parent dialog gets the 'all clear' packet then delete's
the message box that's poped up, calling EndDialog or something, would that
work? if not, what would?