The information in this article applies to:
SYMPTOMSOn an advise loop started with the XTYPF_ACKREQ flag, the item name string is mistakenly removed from the global atom table after a certain period of time causing a subsequent call to DdePostAdvise() on that item name string to fail. CAUSE
For an advise loop started with the XTYPF_ACKREQ flag, DDEML sends the
server application an XTYP_ADVREQ with the LOWORD(dwData1) set to
CADV_LATEACK when the server application calls DdePostAdvise() before the
ACK for the previous update has been received.
RESOLUTIONTo work around this problem, modify your 16-bit server code as described below, freeing the string handle appropriately before returning from the XTYP_ADVREQ transaction:
The function GetDDEMLVer() could be written to return the dwFileVersionMS
member of the VS_FIXEDFILEINFO structure. Refer to the VERSTAMP sample that
shipped with the Microsoft Windows 3.1 SDK and/or Microsoft Visual C++ for
further details about extracting version information.
WIN16APP can be #defined to TRUE if this is a 16-bit version of your application; FALSE otherwise. STATUS
Microsoft has confirmed this to be a bug in Microsoft Windows version
3.1.
Additional query words: 3.10 buglist3.10
Keywords : |
Last Reviewed: November 5, 1999 © 2000 Microsoft Corporation. All rights reserved. Terms of Use. |