-=> Quoting James R. Cook to Phil Crown <=-



 -=> Quoting Phil Crown to James R. Cook <=-

 

 PC> I think you need to reset it, p.exe does not seem to reset the com

 PC> port to its previous state.

 JRC> 

 JRC> Okie.  I'll make it a point to save the state of the port before I

 JRC> fiddle with it.  Say, in your opinion, is it more efficient to buffer

 JRC> the comm port with a thread in the program, or not to worry with it. 

 JRC> I've been turning that one around in my head for a couple of days and

 JRC> I can't see where the overhead would be worth it ...



If its a PM program I would use a thread to avoid blocking the message

queue (main) thread for too long.



Also by using a secondary thread you can adjust the priority.  In my app

the thread that reads the com port runs at PRTYC_TIMECRITICAL and all

the other threads run at PRTYC_REGULAR.



 PC> This is how I found what I believe is a bug in SIO's SU.EXE program.

 PC> Running "su  mode" will not report values
higher than 255 for

 PC> the usWrite/usReadTimeout values, though they are defined as USHORT in

 PC> the DCBINFO structure, and I can set/query them as values higher than

 PC> 255 in my own app.

 JRC> 

 JRC> Interesting.  You let Ray Gwinn know?



Yes, he said he'd look at it.  There are also some grammaticl errors

in SU's reporting (porcess vs. process).



Phil Crown

pcrown{at}airmail.net

http://web2.airmail.net/pcrown/



--- Blue Wave/OS2 v2.30