Changes for Unicode Support in Delphi

From RemObjects Wiki

Jump to:navigation, search

This is a Data Abstract Architecture topic
Feel free to add your notes to this topic below.

This is a RemObjects SDK Architecture topic
Feel free to add your notes to this topic below.

This document describes changes made to RemObjects SDK and Data Abstract for Unicode support introduced in CodeGear Delphi 2009 (aka Tiburon).

In general, we have tried to keep changes as transparent and intuitive as possible, so that in most cases existing applications using our products will "just work" in Delphi 2009. However, since the switch from ANSI to Unicode is especially relevant for wire compatibility, the following notes should be observed.

Changes in RemObjects SDK for Delphi

Where sensible and not affecting wire compatibility, RemObjects SDK will keep using the Delphi 'string' type for public properties and parameters. This will map to UnicodeString in Delphi 2009 and later, and to AnsiString in previous versions.

RemObjects SDK and Data Abstract are preserving complete wire compatibility between Delphi 2008 and previous versions. This means:
- Service interfaces and types defined using the 'String' datatype (now renamed to 'AnsiString', see below) will continue to map to AnsiString and be transmitted as 8-bit strings.
- Any parameters or fields defined as 'WideString' will of course remain Unicode and be sent as 16-bit strings. They will now map to the new UnicodeString type for Delphi 2009.
- Interface units (re)generated with RemObjects SDK 5.0.31 or later will explicitly use AnsiString or UnicodeString in all places. Intf and Invk files will need to be regenerated when upgrading to 5.0.31.
- Caution should be applied to custom code that uses 'string' when interacting with fields or parameters defined in the RODL – implicit up- or down conversion will occur in Delphi 2009, between String and AnsiString.

Library Changes
- A type UnicodeString = WideString alias is defined for Delphi 2007 and below. This allows RemObjects SDK to consistently use 'UnicodeString' to refer to 16-bit strings in all versions.
- The TRODataType enum's 'stString' has been removed, replaced by stAnsiString.
- CodeGen will now emit 'AnsiString' and 'UnicodeString' instead of 'String' and 'WideString' for all versions of Delphi.
- The RODL libraries will update 'String' to 'AnsiString' when loading/saving RODL files (this applies to Delphi and .NET RODL code, as well as Service Builder).
- Service Builder will show 'AnsiString' instead of 'String' in the list of available standard types.

Developer Action Needed

The above adjustments assure that wire compatibility is not broken between Unicode and non-Unicode clients/servers (and .31 and prior clients/servers). However, what will be "broken" (by matter of definition) is code that assumes it can simply pass "String" variables defined in user code (which will be Unicode in Delphi 2008 and beyond) into the existing RODL methods that were defined as "String" (and now "AnsiString"). Conversion and possible data loss will occur here - make sure to enable the Warning provided by Delphi 2009 to catch any potential problems in your code.

One can't have it both ways, and wire compatibility is king. Users moving their application to Delphi 2009 will need to review their String vs AnsiString usage application-wide; they will need to review how code interacts with their String/AnsiString defined RODLs.

Changes Relevant to Users of the .NET Products

Change from 'String' to 'AnsiString' terminology in Service Builder. The 'String' type in Service Builder and RODL Files has always referred to 8-bit ANSI strings, with 'WideString' being available for 16-bit Unicode strings. In .NET, this type mapped to System.String (which is 16-bit), but was marshaled as ANSI using the current code page. For consistency, the 'String' name is being dropped from Service Builder and RODL files, to be replaced by 'AnsiString'.
This is an UI change only, and will not affect the behavior of your applications. Existing RODL files will automatically be upgraded to contain 'AnsiString' when being opened in Service Builder 5.0.31 or later.