Maurizio Lotauro wrote:
> Scrive Arno Garrels <[EMAIL PROTECTED]>:
> First for all, sorry for the delay...

Thanks, for the response!

> But first I would like discuss about the wide string published
> properties. 
> How are they handled by D7 - D2007?
> But how is it stored in the dfm?

This is no longer a problem, since D7 a WideString is stored as Unicode
in both text DFM and binary DFM. Only in the IDE "View DFM as text"  
a WideString may not be displayed correctly.
For instance the WideString "€AB" is stored in text-DFM as 

> Speaking about enhancements, IIRC since a few time the URL has no
> more (or less) limits in the characters that could be used.

I do not understand this sentence?

>>    When you assign an ANSI string
>>    to those properties the string is converted to UTF-16 implicitly
>>    in the background.
> Yes, but do you know how it is done? It should be made assuming that
> the ansi string is "written" using the default character set. So the
> same sequence of byte (remember that an ansi string could be based on
> a MBCS) will converted differently when the default CS is different.

That's true, but this behaviour was exactly the same as with AnsiString.
How do you think the AnsiString "€ÜÄÖ" is displayed in Japanese (CP 932) ;-)
Of course the ICS will provide the required wide-functions so
users can  easily feed the WideString properties with unicode file names.

>>    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.
> This would be true even in D7 - D2007?


>>    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.
> What happen if I load a form created with the "ansi" version of the
> component? 

IMO no problemo, what bad shall happen?

>>    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.
> Why it couldn't be converted directly to UTF-8?

In Windows it's the recommended and default method to use 
MultiByteToWideChar() and WideCharToMultiByte().
Both API functions are very fast and they are used by the RTL as well.

>>       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).
> This is true, but only for the server.

No, the client will have to call the wide-versions of filesytem API functions 
as well in order to handle any possible file name.  

> This point is not clear for me.

The free TNT Unicode controls provide unicode-aware visual controls, their 
Text and Caption properties etc. take WideString(UTF-16).  

>>    e) Explicit conversion from UTF-8 to ANSI with standard controls
>> in D7-D2007.
> True. All these are good points, but only if someone will add the
> UTF-8 support before migrating to D2009. How much are they?
>> Maybe I missed 3). Any idea somebody?
> Add the UTF-8 support only with D2009 and see how many developers
> will ask for the same feature in previous versions :-)

Most work is already done (helper functions and TFtpClient), so why not add it? 
Anyway if someone thinks it's evil please let me/us know. If someone is 
I can send either a TortoiseSVN patch file or the modified files zipped by PM.
Both have to be applied to current ICSv7 available via SVN.      

Arno Garrels

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

Reply via email to