• Welcome to Forum.Deepsoftware.Com. Please login or sign up.
 

Hyperterminal + Asynch work, nrComm won't

Started by onsolution, November 03, 2012, 04:47:47 am

Previous topic - Next topic

onsolution

I have some PCs where the following is happening:
- Hyperterminal works
- An old version of my software using Asynch Pro for the comm port works
- My current version using nrComm won't work. It opens the port but hears nothing.

The software works on many PCs so I know it's not a blatant bug (e.g. baud rate setting etc).

I run the old version and it works. The new version won't. Then I rerun the old version and it still works. So the only difference is the serial port control that I am using.

Is there anything under the hood that works differently to hyperterminal and Asynch pro? I thought they all just used the Windows APIs.

Roman Novgorodov

Hello

APro is not equal nrComm Lib.
HT is not equal nrComm Lib.

Please create simple project that does not read data from serial port and upload it here.
Also you can try sample projects from nrComm Lib Demos folder.
For start You can run Codes demo for monitor HEX/DEC codes of all incoming data.

Possible you select non correct port setting: baud rate, stream protocol etc.
I need more info if you want help from us.

Roman Novgorodov
DeepSoftware llc
DeepSoftware llc - The professional components for Delphi/CBuilder/.NET. The high quality custom software development.
Forums.nrCommLib.Com - DeepSoftware Tech Support Forum.

onsolution

The OnAfterReceive isn't triggering, but if I call ReadString I can retrieve the incoming data. So now I have a timer polling it frequently.

So baud rate etc are all fine. It works on most PCs. There's just a couple where the events have stopped firing.

So what triggers the events? Sorry, the source code is missing from my installation otherwise I would try trace it back.

onsolution

The plot thickens.

For some labels the line:
ts:=comport.ReadString;
(where ts is an ansistring) would throw in some letters instead of just barcode numbers. I assume it is because of unicode conversion along the way.

So I then went for:
buffersize:=comport.ReadyForRead;
if buffersize > 0 then
begin
      comport.Read(@newmsg[1], buffersize);

Which worked fine for me, but not for them. Buffersize on some of there PCs was always 0.

But that was yesterday as I was trying to get this working from an airport and I am rushing to catch a 3 hour flight.

This morning it is working sporadically for them. So that's an improvement from doing absolutely nothing.