Porting a Delphi 2006 app to XE

Question

I am wanting to port several large apps from Delphi 2006 to XE. The reasons are not so much to do with Unicode, but to take advantage of (hopefully) better IDE stability, native PNG support, more components, less VCL bugs, less dependence on 3rd party stuff, less ribbing from you guys, etc. Some of the apps might benefit from Unicode, but that's not a concern at present. At the moment I just want to take the most direct route to getting them to compile again.

As a start, I have changed all ambiguous string declarations, i.e. string to AnsiString or ShortString, char to AnsiChar and pChar to pAnsiChar and recompiled with D2006. So far so good. Nothing broke.

My question is: Where to from here? Assuming I just present my sources to the XE compiler and light the touch paper, what is likely to be the big issue?

For example,

var
    S : AnsiString ; 
...
MainForm.Caption := S ;

Will this generate an error? A warning? I'm assuming the VCL is now Unicode, or will XE pull in a non-Unicode component, or convert the string? Is it in fact feasible to keep an app using 8-bit strings in XE, or will there be too many headaches?

If the best/easiest way to go is to Unicode, I'll do that, even though I won't be using the extended characters, at least in the near future anyway.

The other thing that I wonder about is 3rd party stuff. I guess I will need to get updated versions that are XE-compatible.

Any (positive!) comment appreciated.

Answer 1

The VCL is completely Unicode now, so the code you showed will generate a compiler warning, not an error, about an implicit conversion from AnsiString to UnicodeString. That is a potentially lossy conversion if the AnsiString contains non-ASCII characters (which the compiler cannot validate). If you continue using AnsiString, then you have to do an explicit type-cast to avoid the warning:

var
  S : AnsiString ; 
...
MainForm.Caption := String(S);

You are best off NOT Ansi-fying your code like this. Embrace Unicode. Your code will be easier to manage for it, and it will be more portable to future versions and platforms. You should restrict AnsiString usage to just those places where Ansi is actually needed - network communications, file I/O of legacy data, etc. If you want to save memory inside your app, especially if you are using ASCII characters only, use UTF8String instead of AnsiString. UTF-8 is an 8-bit encoding of Unicode, and conversions between UTF8String and UnicodeString are loss-less with no compiler warnings.

Answer 2

It is a long jump taking 2006 to 2011

But it is possible if you consider that:

• You have to convert String variables using the new conversions methods ;
• You have to check all the versions between 2006 and xe to know how the libraries have changed, bacause some have been spplited, others merged, and a few deleted ;
• You have to buy/download the upgrade (if any) of your 3rd party components.