FIX: Posting WM_COMMNOTIFY Messages May FailLast reviewed: October 29, 1997Article ID: Q108309 |
3.10
WINDOWS
kbprg kbbuglist kbfixlist
The information in this article applies to:
SYMPTOMSWhen using WM_COMMNOTIFY messages in a communications application, these messages may appear to have stopped being posted.
CAUSEWhen COMM.DRV calls PostMessage(), it does not check the return value. Even if PostMessage() fails, it appears to COMM.DRV that the message was sent. For CN_EVENT notifications, the event must be cleared using GetCommEventMask() before a new CN_EVENT notification will be sent. If the application never receives the CN_EVENT notification, the event never gets cleared, so COMM.DRV will not send a new CN_EVENT notification. If this happens, the notification process appears to have stopped. Similarly, for CN_RECEIVE and CN_TRANSMIT notifications, if these notifications are not received, the application may not know to do a ReadComm() or WriteComm(). If ReadComm() or WriteComm() is never called, the character level will never cross the buffer threshold to create a new notification. For more information on how CN_RECEIVE and CN_TRANSMIT notifications are generated, query on the following words in the Microsoft Knowledge Base:
docerr and CN_RECEIVE and events and generated RESOLUTIONImplement a polling strategy to determine communications status, in addition to using WM_COMMNOTIFY messages. This could be implemented in the message loop of the application, or by using a timer.
STATUSMicrosoft has confirmed this to be a problem in Windows version 3.1. This bug has been corrected in later versions of Microsoft Windows.
|
Additional reference words: 3.10 buglist3.10
© 1998 Microsoft Corporation. All rights reserved. Terms of Use. |