Maurizio Lotauro wrote:
> I followed the whole thread, and my opinion is that adding this
> feature to D7 - D2007 compiler is not good if this imply to break
> existing code, in particular when D2009 is ready to ship.
> If the programmer should rework its code it is better that is for
> D2009 than for an old version.

Agreed, however ICSv7 is a new beta and as such breaking changes should
be IMO possible, especially when new, long missing features cannot be
implemented properly without a harmless break.
I think there are two options

1) Currently this is my preference, implemented already
   sucessfully in my code.
   I introduced an alias:
   {$IFDEF D7-D2007} UnicodeString = WideString {$ENDIF}
   and changed three properties, HostFileName, LocalFileName and
   HostDir from "String" to "UnicodeString".   
   This works smoothly without further code changes in all Delphi
   versions from D7 to D2009 because WideString and String are 
   assignment compatible, even in D7! When you assign an ANSI string
   to those properties the string is converted to UTF-16 implicitly
   in the background. In D2009 UnicodeString is the default string 
   type, String maps to UnicodeString in D2009.   
   The TFtpClient got a new property "CodePage" that defaults to
   the default system code page. By simply setting it to CP_UTF8
   UTF-8 capability is turned on. That even allows you to select an 
   ANSI code page which is not the default system code page,
   usefull if a server does not support UTF-8 and uses a different
   ANSI code page than client's default code page.
   Well my implementation _might break existing code, however user
   code that instantiated TFtpClient directly would continue to work
   w/o a change. In classes derived from TFtpClient it would be very 
   easy to exchange "String" by "UnicodeString" here and there if
2) Currently this is Francois' and Angus' preference, however
   not yet implemented.
   Properties are not changed. In order to support Unicode the
   component user would have to convert those strings explicitly
   to UTF-8 before assigning them to the properties. 
   IMO that has multiple disadvantages:   
   a) In order to convert an ANSI string to UTF-8 the string
      has to be converted twice, first to UTF-16 and the from UTF-16
      to UTF-8, same the other way around.
      The UTF-8 string has to be converted also to UTF-16 before any 
      call of the Win-API, which will decrease performance,
      and most likely compensate the performance penalty of using 
      WideString in 1).      
   b) In order to support UTF-8, users need to change more code and
      after an upgrade to D2009 once again.
   c) More difficult to support ANSI code pages beside the default 
      system code page.   
   d) Explicit conversion from UTF-8 to UTF-16 required with TNT controls.   
   e) Explicit conversion from UTF-8 to ANSI with standard controls in D7-D2007.

Maybe I missed 3). Any idea somebody?

Arno Garrels

To unsubscribe or change your settings for TWSocket mailing list
please goto
Visit our website at

Reply via email to