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 #8364'AB'. > > 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? Yes. > >> 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 interested 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 http://lists.elists.org/cgi-bin/mailman/listinfo/twsocket Visit our website at http://www.overbyte.be
