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
neccessary.
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 http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket
Visit our website at http://www.overbyte.be
