1

I have a case here, I am going to migrate over to delphi 2011 XE from Delphi 7, and to my surprise many components will have problems due to ansistrings, in delphi xe they look like japanese / chinese characters, now the unit I use is a PCSC connector and seem to be discontinued/abandoned from the original developper.

basically what I want is a easy way to read the strings again with as little modification to original code as possible..

also if there are any good tutorials out there on how to makae components ansistring ready for 2009 and newer would help me also

David Heffernan
  • 601,492
  • 42
  • 1,072
  • 1,490
Plastkort
  • 957
  • 1
  • 26
  • 40

2 Answers2

9

@Plastkort, Delphi >= 2009 is perfectly capable of reading and handling AnsiString. You only get the meaningless characters if you somehow hard-cast ANSI data to Unicode, possibly by hard-casting a pointer to PChar.

If I had to convert someone else's code to Unicode I'd start by searching for PChar, Char and String and specifically looking at places where other types are hard casted to those types. That's because those types changed meaning: In non-Unicode delphi CHAR was 1 byte, now it's 2 bytes.

The conversion itself isn't necessary difficult, you just need to understand the problem you're facing and you need to have good understanding of the code you're converting. And it's a lot of work, especially when dealing with code that did "smart things with strings".

Cosmin Prund
  • 25,498
  • 2
  • 60
  • 104
1

The big change in Delphi (prior to Delphi 2009 I think) is the aliased string types; string, Char, PChar, etc which prios to 2009 were ANSI string types are now all WideChar types.

so 

Type   | Delphi 6,7 | Delphi 2009, XE
-------+------------+----------------
string | AnsiString | UnicodeString
char   | AnsiChar   | WideChar
pchar  | PAnsiChar  | PWideChar

The simplest way to migrate from Ansi Delphi to Unicode Delphi is a global search and replace for the aliased string types that replaces them with the explicit 8 bit ANSI equivlents (i.e. replace all string with AnsiString, PChar with PAnsiChar, etc...)

That should get you 90% of the way.

update After reading the comments to my answer and the article referenced by @O.D I think the advice to bite the bullet and go with Unicode is the wiser option.

Lars Truijens
  • 42,837
  • 6
  • 126
  • 143
Pete Stensønes
  • 5,595
  • 2
  • 39
  • 62
  • 7
    I would like to recommend the opposite. Embrace the change to Unicode and change your application to work properly with Unicode. – Mikael Eriksson Feb 24 '11 at 10:56
  • That would be prefereable in the long term. But my answer was based on Plastkort's request for the **easiest** wat to get his app working again. Long term embracing unicode is the correct answer but I would argue its probably a lot more work in the short term. – Pete Stensønes Feb 24 '11 at 11:00
  • It's probably easier to embrace in my opinion! – David Heffernan Feb 24 '11 at 11:03
  • 2
    In Delphi 2009+ string is a UnicodeString, not a WideString (which is not reference counted and slower in most cases) – Jens Mühlenhoff Feb 24 '11 at 11:04
  • 3
    @Pete, "embracing the change" and convert to Unicode might actually be faster. I'd expect most of the OP's application to use STRING exclusively. If you fall into the trap of converting all strings to AnsiString and all Chars to AnsiChars *in one unit*, you'll end up doing the same all over the place, because all your other code is interfacing with that unit. And you can't change everything because the VCL is now Unicode, so you'll get warnings when you try to set a control's Caption to some string because you just changed your local variable from string to AnsiString. – Cosmin Prund Feb 24 '11 at 11:22
  • When converting old code that uses PChar just as pointers to bytes it is actually easier going with the PAnsiChar route. – Leonardo Herrera Feb 25 '11 at 17:36