>The problem is sometimes the COMM.DRV don't post back the WM_COMMNOTIFY
>message to my app. This seems occur when the app create a lot of window.
You have to make sure you clear any errors that occur. I wrote an application
last year that used WM_COMMNOTIFY very successfully, but at first I kept
encountering errors that would seem to stop future notifications, as you
describe. Then I learned how to clean up the errors as they happened, and
that allowed the program to again retreive data. However, I kept getting
occasional errors. The biggest solution for me was to increase the size of my
read buffer so it never overflowed -- these read-buffer-overflow errors were
the main source of trouble for me.
At any rate, here is an edited version of my OnCommNotify function:
LONG CPortMonitor::OnCommNotify(WPARAM wParam, LPARAM lParam)
int nDeviceID = (int) wParam;
LPARAM lEventType = lParam;
// First clear any errors
if (lEventType & CN_EVENT)
UINT uEventMask = GetCommEventMask(nDeviceID, EV_ERR);
// This had better be an error
if (uEventMask & EV_ERR)
// Clear the errors. I don't know if it is necessary to loop
// on this, but the Microsoft "COMM" sample program does this...
while (nCommError = GetCommError(nDeviceID, &CommStatus))
// Now repair the damage...
// Now process any pending characters
if (lEventType & CN_RECEIVE)
// Read characters one at a time... This is slow but my
// application operated with devices that never exceed
// 9600 baud anyway, so this is more than adequate.
while (ReadComm(nDeviceID, &ch, 1) > 0)
if (! ProcessChar(ch))
// Always indicates successful processing of the event