RESOLUTION
This limitation is by design. DDEML applications can work around this
limitation by installing a WH_MSGFILTER hook, watching out for code ==
MSGF_DDEMGR.
The WH_MSGFILTER hook allows an application to filter messages while
the system enters a modal loop, such as when a modal dialog box (code
== MSGF_DIALOGBOX) or a menu (code == MSGF_MENU) is displayed; and
similarly, when DDEML enters a modal loop in a synchronous transaction
(code == MSGF_DDEMGR).
The Windows 3.1 Software Development Kit (SDK) DDEML\CLIENT sample
demonstrates how to do this in DDEML.C's MyMsgFilterProc() function:
/**********************************************************************
*
* FUNCTION: MyMsgFilterProc
*
* PURPOSE: This filter proc gets called for each message we handle.
* This allows our application to properly dispatch messages
* that we might not otherwise see because of DDEMLs modal
* loop that is used while processing synchronous transactions.
*
***********************************************************************/
DWORD FAR PASCAL MyMsgFilterProc( int nCode, WORD wParam,
{
#define lpmsg ((LPMSG)lParam)
if (nCode == MSGF_DDEMGR) {
/* If a keyboard message is for the MDI, let the MDI client
* take care of it. Otherwise, check to see if it's a normal
* accelerator key. Otherwise, just handle the message as usual.
*/
if ( !TranslateMDISysAccel (hwndMDIClient, lpmsg) &&
!TranslateAccelerator (hwndFrame, hAccel, lpmsg)){
TranslateMessage (lpmsg);
DispatchMessage (lpmsg);
}
return(1);
}
return(0);
#undef lpmsg
}