Delphi 2010 can't RECEIVE 128 (x80) fro...

Ian C
2011-11-15
2013-04-30
  • Ian C

    Ian C - 2011-11-15

    Using D2010 and Comport 4.11

    If the received data packet contains a 128 ($80) then that byte is translated to $AC for some reason. You never get to see 128s in the input data stream.
    NOTE: This only happens if reading a 'string'.

    comport.read(… ) works OK because buff is untyped.
    comport.readstr(…) translates all occurrences of $80 to $AC.

    Sadly, DataPacket events all use string type parameters.  If I want to use datapackets then I'm stuck with strings. Either way, the 128s in the input data stream shouldn't get messed with.

    Ideas?

     
  • Brian Gochnauer

    Brian Gochnauer - 2011-11-16

    Make sure you use 8 data bits to send and receive.

    128 decimal is hex 80 or binary 1000 0000
    Since 128 is the eighth bit  if you use 7 data bit settings you will not receive anything, but null (zero)

     
  • Ian C

    Ian C - 2011-11-17

    Thanks for your response Brian. I appreciate it.

    I already am using 8 data bits.  In my post above I noted that it works correctly if I do an untyped Comport.Read( buff … ).  The problem arises when I use the ReadStr method.  For some reason, with ReadStr, every 80h in the inbound data stream gets replaced with a ACh.

    For example (in hex):

    Inbound data:  FE FE 64 E0 34 51 80 66 37 FD
    ReadStr data:  FE FE 64 E0 34 51 AC 66 37 FD  <-- corrupt data (ACh should be 80h)
    Read data: FE FE 64 E0 34 51 80 66 37 FD  <-- correct data

    Hopefully I have been a little clearer now.

    (BTW, it would be nice if DataPackets weren't so "String" centric and also supported untyped data)

     
  • Brian Gochnauer

    Brian Gochnauer - 2011-11-17

    Is there a difference in results if you use ReadUnicodeString instead of ReadStr ?

     
  • Ian C

    Ian C - 2011-11-17

    Bingo!  I found the problem.  It's in line 1929 of CPort.pas -->   str := String(Sa);

    Casting an ansiString into a String (strings are WideStrings in D2010) is the problem.  See sample code…

    procedure StringProblem;
    var
      sa: ansiString;
      s1: String;
    begin

         sa := ansistring(ansiChar($80));
         showmessage( IntToHex( byte(sa), 2 ) );   // sa is $80 as expected

         s1 := string(sa);                            // now cast to string - line 1929

         showmessage( IntToHex( byte(s1), 2 ) );   // after casting, it becomes $AC - should still be $80

    end;

     
  • Brian Gochnauer

    Brian Gochnauer - 2011-11-17

    i did some testing and put a cport.pas file at the previous link.
    It looks something like
              for i := 0 to length(sa) do str_ := char(byte(sa));
    seems to work_

     
  • Brian Gochnauer

    Brian Gochnauer - 2011-11-17

    for i := 0 to length(sa) do str[i] := char(byte(sa[i]));

     
  • Brian Gochnauer

    Brian Gochnauer - 2011-11-17

    can't post without screwing up the REAL code

    for i := 0 to length(sa) do str_ := char(byte(sa));_

     
  • Ian C

    Ian C - 2011-11-17

    The first Cport.pas file that you sent didn't work.  I think I see where you were going though.

    However it turns out that   sWide := UTF8Decode( ansiToUTF8( sAnsi ) yields the same result as  sWide := string( sansi ) for 80h.

    I haven't looked at your second file yet, but didn't you mean:

       for i := 1 to length(sa) do str := str + char( byte(sa_) );

    I'll check.
    _

     
  • Ian C

    Ian C - 2011-11-17

    ignore my comment about your code loop above (for i := …).  I see that the 'square brackets' got removed in posting.

     
  • Ian C

    Ian C - 2011-11-17

    Ok, the last file that you sent me seems to work OK.  Make sure that you start 'i' at 1 however (for i := 1 to length(sa) do…).  Note: I haven't checked to see if DataPackets work with this change for 80h

    There's also a rogue semicolon in the method just above it. (ReadStrAsync)  It's obvious.

    Thanks Brian.
    BTW, I'm new with SourceForge.  How will I know when the release containing this fix becomes available?

    Ian

     
  • Ian C

    Ian C - 2011-11-17

    Update…  I just tested and confirmed that DataPackets don't work and need the same change.   TComDataPacket.RxBuff procedure requires the same fix.  See -->   Str := String(sa);   somewhere around line 3260.

    Ian

     
  • Brian Gochnauer

    Brian Gochnauer - 2011-11-17

    thanks.
    I sent up a new file, I'll update soon.

     
  • Stephen Gaunt

    Stephen Gaunt - 2013-01-29

    Just to add I was having the same problem, values greater than $7F  did not convert correctly. Something to do with Unicode, as $80 is not a valid Unicode value, trying with higher (valid) Unicode values and it is OK, but several values wont work not just $80.
    Anyway I replaced CPort.pas  with the latest version recompiled the component and now its OK!
    Cheers Brian

     

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:





No, thanks