Re: capturing windows messages to parent dialog box

From:

"AliR $VC++ MVP$" <AliR@online.nospam>

Newsgroups:

microsoft.public.vc.mfc

Date:

Fri, 14 Sep 2007 20:27:52 GMT

Message-ID:

<c9CGi.4780$FO2.1377@newssvr14.news.prodigy.net>

I am not a 100% sure but that should take care of it.

In your current method, when the thread calls the dialogs ProcessPacket
method, that method pops up a message box which will block the thread. Once
you change that method call to a PostMessage, then the receiver thread will
no longer block as a result of ProcessPacket not returning in a timely
manner.

If the second message is still not comming through, you might just have to
disable the parent window and popup a modeless dialog to simulate a modal
dialog/message box.

AliR.

"Srivatsan "Vat" Raghavan" <SrivatsanVatRaghavan@discussions.microsoft.com>
wrote in message news:89000DD0-8EFD-4B08-9239-5BE50AD31D3D@microsoft.com...

ok, i'll do that, but does that resolve my underlying issue with the modal
message box?

"AliR (VC++ MVP)" wrote:

Ouch, Instead of calling the dialog method directly you should post a
message to it. This way it won't block your messaging thread.

#define WM_PROCESSPACKETS WM_APP + 1

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->PostMessage(WM_PROCESSPACKETS);
    }

    pDlg->m_bThreadEnd = true;
    return 0;
}

AliR.

"Srivatsan "Vat" Raghavan"
<SrivatsanVatRaghavan@discussions.microsoft.com>
wrote in message
news:988B5AB1-D440-4807-B661-481F6EF12419@microsoft.com...

"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?