Scrive Arno Garrels <[EMAIL PROTECTED]>: First for all, sorry for the delay...
> 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. Generic speaking I agree with you, but this is a particular situation so maybe it should be handled differently. But first I would like discuss about the wide string published properties. How are they handled by D7 - D2007? What I expected is that the OI handled it like the dbedit with wide string fields, that is it made a conversion from ansi di wide string based on the current character set. That's fine. But how is it stored in the dfm? I expected that it will stored as ansi. If this is true then when it is loaded it is converted again from ansi to wide string, based on the current character set. This mean that if the CS is different from the "original" you will get a different result. If this is true then I doubt that this kind of inconsistency is acceptable. Can you confirm this? Speaking about enhancements, IIRC since a few time the URL has no more (or less) limits in the characters that could be used. > I think there are two options > > 1) Currently this is my preference, implemented already > sucessfully in my code. [...] > 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. > 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? > 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. Why it couldn't be converted directly to UTF-8? > 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. > b) In order to support UTF-8, users need to change more code and > after an upgrade to D2009 once again. True > c) More difficult to support ANSI code pages beside the default > system code page. True > d) Explicit conversion from UTF-8 to UTF-16 required with TNT controls. This point is not clear for me. > 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 :-) Bye, Maurizio. ---------------------------------------------------- This mail has been sent using Alpikom webmail system http://www.alpikom.it -- 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
