INFO: Do Not Forward DDEML Messages from a Hook Procedure

Last reviewed: January 12, 1998
Article ID: Q89828
The information in this article applies to:
  • Microsoft Windows Software Development Kit (SDK) version 3.1
  • Microsoft Win32 Application Programming Interface (API) included with: - Microsoft Windows NT versions 3.5, 3.51 - Microsoft Windows 95

SUMMARY

If an application for Windows uses the Dynamic Data Exchange Management Library (DDEML) in addition to a message hook [for example, by calling SetWindowsHook() or SetWindowsHookEx()], it is possible that your hook procedure will receive messages that are intended for the DDEML libraries.

For the DDEML libraries to work properly, you must make sure that your hook function does not forward on any messages that are intended for the DDEML libraries.

MORE INFORMATION

If your hook procedure receives a code of type MSGF_DDEMGR, you should return FALSE instead of calling the CallNextHookEx() function.

Use the following code to handle this situation:

   // This needs to be defined if you haven't already.
   #ifndef MSGF_DDEMGR
   #define MSGF_DDEMGR             0x8001
   #endif

   if (MSGF_DDEMGR == code)
      return FALSE;
   else
   {
   ...
   }

In cases where the callback function processes the message, it should return TRUE.

Note, however, how the message filter function is called from within DDEML:

   while (TimeOutHasntExpired) {
       GetMesage (&msg, (HWND)NULL, 0, 0);
       if ( !CallMsgFilter (&msg, MSGF_DDEMGR))
            DispatchMessage (&msg);
    }

Given this, a callback function that just returns would cause the CallMsgFilter() call above to return TRUE, and never dispatch the message. This inevitably causes an infinite loop in the application, because GetMessage() ends up retrieving the same message over and over, without dispatching it to the appropriate window for processing.

Therefore, a callback function that processes the message may not just return TRUE, but should also translate and dispatch messages appropriately.

The Windows 3.1 SDK's DDEMLCL sample demonstrates how to do this correctly in its MessageFilterProc() found in DDEMLCL.C:

   if (nCode == MSGF_DDEMGR) {

   /*
   * If a keyboard message is for MDI, let MDI client take care of it.
   * Otherwise, check to see if it is 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;
    }

For more information about message hooks and DDEML, please see the above mentioned functions in the Windows SDK manual or the online help facility.


Additional query words: 3.00
Keywords : UsrDde
Platform : Win95 WINDOWS winnt
Issue type : kbinfo


THE INFORMATION PROVIDED IN THE MICROSOFT KNOWLEDGE BASE IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. IN NO EVENT SHALL MICROSOFT CORPORATION OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS OR SPECIAL DAMAGES, EVEN IF MICROSOFT CORPORATION OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES SO THE FOREGOING LIMITATION MAY NOT APPLY.

Last reviewed: January 12, 1998
© 1998 Microsoft Corporation. All rights reserved. Terms of Use.