The information in this article applies to:
SYMPTOMSA common symptom of this problem is seen as the client processes user input while inside DDEML's modal loop in a synchronous transaction. WM_KEYDOWN and WM_KEYUP messages are received, with no corresponding WM_CHAR message for the typed character. During a synchronous transaction, DDEML causes the client to enter a modal loop until the transaction is processed. While DDEML dispatches messages appropriately, it fails to call TranslateMessage() while inside this modal loop. This problem does not apply to asynchronous transactions, where no such modal loop is entered. CAUSENo WM_CHAR message is received because the WM_KEYDOWN message is never translated. For this to take place, a call to TranslateMessage() must be made inside the modal loop. 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.
*
* 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 lParam)
wParam; // not used
if (nCode == MSGF_DDEMGR) {
if ( !TranslateMDISysAccel (hwndMDIClient, lpmsg) && !TranslateAccelerator (hwndFrame, hAccel, lpmsg)){ TranslateMessage (lpmsg); DispatchMessage (lpmsg); } return(1); } return(0);
Additional query words: 3.10 3.50 4.00
Keywords : |
Last Reviewed: September 21, 1999 © 2000 Microsoft Corporation. All rights reserved. Terms of Use. |