Help : No WM_COMMNOTIFY sent back from COMM.DRV

Help : No WM_COMMNOTIFY sent back from COMM.DRV

Post by w.. » Sat, 31 Aug 1996 04:00:00



hi, Every one:
  I'm writting a serial communication mfc program under MSVC v1.52.
  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.

  Any ideas?

  David Z.W

 
 
 

Help : No WM_COMMNOTIFY sent back from COMM.DRV

Post by Richard Clark » Mon, 02 Sep 1996 04:00:00



writes

Quote:>hi, Every one:
>  I'm writting a serial communication mfc program under MSVC v1.52.
>  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.

>  Any ideas?

>  David Z.W

Don't rely on WM_COMMNOTIFY as the standard COMM.DRV is notoriously
buggy. You're better off reading the port directly. You should check
there is data in the input queue as ReadComm() will block; you should
also check there is sufficient room in the output queue before using
WriteComm(). I have written lots of comms programs in 1.51 and never
needed WM_COMMNOTIFY.

If you want to use baud rates above 19,200 check you have a 16550 UART
(standard with recent hardware).

By the way, don't be tempted to put anything in your OnIdle() function
(a logical place you might think to do background comms processing).
When you run your app under Windows 95 you'll find that OnIdle() isn't
always called.

--
Richard Clarke
http://www.richardc.demon.co.uk    :   Programmers' Archives

 
 
 

Help : No WM_COMMNOTIFY sent back from COMM.DRV

Post by Richard Clark » Mon, 02 Sep 1996 04:00:00





>writes
>>hi, Every one:
>>  I'm writting a serial communication mfc program under MSVC v1.52.
>>  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.

>>  Any ideas?

>>  David Z.W

>Don't rely on WM_COMMNOTIFY as the standard COMM.DRV is notoriously
>buggy. You're better off reading the port directly. You should check
>there is data in the input queue as ReadComm() will block; you should

^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Bit of brain-fade there. ReadComm() won't block (unlike unix 'read').
However you should always remember to call GetCommError() to clear any
error conditions before using any I/O functions.
--
Richard Clarke
http://www.richardc.demon.co.uk    :   Programmers' Archives

 
 
 

Help : No WM_COMMNOTIFY sent back from COMM.DRV

Post by Jim McCa » Wed, 04 Sep 1996 04:00:00



>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)
      {
         COMSTAT   CommStatus;
         int       nCommError;
         char      szError[100];

         // 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...
            FlushComm(nDeviceID, 1);
            ClearCommBreak(nDeviceID);
         }
      }
   }

   // Now process any pending characters
   if (lEventType & CN_RECEIVE)
   {
      char   ch;

      // 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))
            break;
      }
   }

   // Always indicates successful processing of the event
   return 0;

Quote:}

 
 
 

Help : No WM_COMMNOTIFY sent back from COMM.DRV

Post by Robert A. Zawars » Wed, 11 Sep 1996 04:00:00



>Don't rely on WM_COMMNOTIFY as the standard COMM.DRV is notoriously
>buggy. You're better off reading the port directly. You should check
>there is data in the input queue as ReadComm() will block; you should
>also check there is sufficient room in the output queue before using
>WriteComm(). I have written lots of comms programs in 1.51 and never
>needed WM_COMMNOTIFY.
>By the way, don't be tempted to put anything in your OnIdle() function
>(a logical place you might think to do background comms processing).
>When you run your app under Windows 95 you'll find that OnIdle() isn't
>always called.

Richard, I sent you e-mail but maybe others are interested..

So  what are my MFC/3.11 alternatives to the above two
methods? How do I "poll" the comm besides using
"WM_COMMNOTIFY" or an OnIdle routine? When/if
I write a 95 version I will of course use threads but
I would like it to run as is under 95...

If anyone is interested, I am creating an MFC terminal class
mostly based on routines from "Windows Programmers
Guide to Serial Communications" by Timothy S. Monk. It's
an old book, 1992, and there is no info in it regarding
the redistribution of the code. I wrote the author and
if everything is OK, I am going to be sticking my work
on a web page so others can use/fix/improve it. (or as
soon as I get a reply I will mail the hacks in progress to
anyone interested...)

Rob Z.

 
 
 

1. NT 3.5 Server-Use Comm.drv or Cybercomm.drv?

I recently switched to NT 3.5 Server and I know that in Windoze 3.1 I
replaced the comm.drv with Cybercomm.drv. Has anyone replaced the
comm.drv in NT and where would I set up this new driver if I did
switch it?
                                Thanks,
                                FM

2. re lost word document!!

3. replacing comm.drv with a turbo.drv

4. Help: no sound from CD

5. comm.drv file missing "Help"

6. Activation Help!

7. Win95 Comm.DRV HELP!!

8. Unable to Install IE 6.0 SP 1

9. Missing a "comm.drv"

10. missing COMM.DRV

11. comm.drv

12. Missing COMM.DRV