Changes for Unicode Support in Delphi
From RemObjects Software
NOTE: This is article is a work in progress and not finished yet.
Unless you are the author, please do not make changes or rely yet on information presented in this article.
When done, the author should change the first line from wip to wipr to show that the page is ready for review.
If you have suggestions for this page, please send them to us: email.
This document describes changes made to RemObjects SDK and Data Abstract for Unicode support introduced in CodeGear Delphi 2008.
In general, we have tried to keep changes as transparent and intuitive as possible, so that in most cases existing Vinci applications will "just work" in Delphi 2008. 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 2008, and to AnsiString in previous versions
- RemObjects SDK is preserving complete wire compatibility between Delphi 2008 and previous versions.
- 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 introduced in Delphi 2008.
- Interface units (re)generated with RemObejcts 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 2008, 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 the 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 just 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.
One can't have it both ways, and wire compatibility is king. Users moving their application to Delphi 2008 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, but was marshaled as ANSI using the current code page. For consistency, the 'String' name is being dropped form Service Builder and RODL files, to be replaced by 'AnsiString'.
This is a 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.
Product: RemObjects SDK
Current version: RemObjects SDK 'Vinci' (5.0)
Lists — Glossary — Features — How To — Components — Tools — Samples — Articles — Architecture — Issues
Product: RemObjects Data Abstract
Current version: Data Abstract 'Vinci' (5.0)
Lists — Glossary — Features — How To — Drivers — Components — Tools — Samples — Articles — Architecture — Issues
