Yes, the evil of a standard ASSERT dialog is that it allows recursion. The
"Joseph M. Newcomer" <newcomer@flounder.com> wrote in message
news:qmubt2dks40pq91j1oq2u28u323e4tibvp@4ax.com...
Not sure what the discussion of stuff coming in from the network relates
to, because if
the main app doesn't have a message pump, then you are not using
CAsyncSocket, and for
low-level socket work a message pump isn't relevant to the discussion.
If
you are using
CAsyncSocket in your thread, then the MessageBox pump will happily
dispatch the network
messages anyway. MessageBox doesn't stop other messages from happening
(although it will
discard thread messages).
Never tried using CAsyncSocket. The pattern, which I've seen many times
over
the years, is:
(1) There's a bunch of network code written in portable fashion, so the
application protocol stack is shared with the Linux or embedded or
whatever
widget at the other end of the connection.
(2) This uses the basic socket API in its own threads. CAsyncSocket is not
relevant to portable code.
(3) When it has decoded a high-level incoming message it wraps it up in a
custom Windows message and posts it to the main GUI thread for further
processing, including updating the GUI, which is easier to do if it's all
kept in the one main thread.
(4) If the GUI thread puts up a conventional ASSERT dialog these messages
continue to be pumped, and destroy the environment you were trying to
debug,
eg popping up hundreds of further ASSERT dialogs faster than you can close
them down.
(5) So you have a custom assert which pops up the message box in a
separate
thread, and does WFSO for that thread to finish, thus preserving the
environment for you to poke around in with the debugger.
I agree that this is primarily a debug scenario - you don't expect this to
be part of the day-to-day operation of the released version of the product
in the field.
--
Tim Ward
Brett Ward Limited - www.brettward.co.uk