On Tue, 15 Aug 2017 21:22:10 +0200, Luca Olivetti via Lazarus <lazarus@lists.lazarus-ide.org> wrote:
>(I remarked the "if" because I don't know if that's the case, according >to Bo Berglund's experience it is) Just to expand on my "experience" and the reason I posted: My work on converting the old program started back a couple of years when I went from Delphi 2007 (pre-unicode) to Delphi XE5 because we wanted the GUI to be translatable to non-western languages. But then all the communications functions (and these are many in this utility application) broke because they used strings as containers for the inherently binary serial data. So I followed advice on the Embarcadero forum to switch to AnsiString because that was really what the old string type was an alias for. I had no great insight in the inner workings of the string handling functions but I "knew" that AnsiString was a 1-byte per element and (unicode)string was now a 2-byte per element container. The fact that the code could alter the content of the AnsiString did not dawn on me at all. And the comm functions worked fine after the change (I tested a lot, but of course only on my English Win7 computer). Then some time ago there was a report of a failure of the new program version that only happened in Korea, China and Thailand. In the log files there was a very strange entry about finding an illegal command byte when sending a command to the equipment. It never triggered when I debugged the problem, for me and my collegues it worked flawlessly. So I had to add more logging and found that the problem arose when the outgoing command was built. A certain 1-byte command was then expanded to 2 bytes with the wrong first byte! The commands in the protocol are the first byte of the data of a telegram and they are in range $C0..$E9. When one of these (I don't now remember exactly which one) was used in an assignment to the AnsiString buffer it was converted to $3F + something that was never logged and the operation failed because the equipment could not decode the command. So I asked again on the forum and was steered towards RawByteString because presumably that container would disallow conversions. And when I changed this and sent a new version to the distributor in Korea the problem was seemingly gone. Based on this experience I wanted to alert the OP of the fact that using AnsiString instead of string is not a cure-all for binary data, you need to fix the codepage too, which is what the RawByteString does for you.... But I have now moved on and replaced all comm related containers with TBytes including modifying the serial component we have used. (With some help from Remy Lebeau). -- Bo Berglund Developer in Sweden -- _______________________________________________ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus