On Sat, Dec 21, 2013 at 3:08 AM, Marcos Douglas <[email protected]> wrote: > I didn't understand. If I have a TStringList instance, on Windows, I > need to convert Text property to ANSI. But some components, e.g. > TMemo, do these conversions automatically, but this is different.
TMemo is a GUI component. Then the string encoding matters and it must be converted to the native widgetset encoding. Still, the conversion is automatic. You don't need to care about it if you work with LCL components only and not with WinAPI directly. TStringList is not a GUI component. It can be used for example in an embedded Linux program with no GUI. It does not need to know the encoding (except for sorting maybe). With FPC no automatic conversions happen. In Delphi things are different. The auto-conversion happens ALWAYS when assigning between eg. UTF-8 and UTF-16. It has nothing to do with WinAPI, or any other widgetset API. Native string is UTF-16. If you have var MyUTF8Str: UTF8String; ... StringList.Add(MyUTF8Str); <- triggers conversion MyUTF8Str := StringList[0]; <- triggers conversion again The amazing thing is that such code works. Delphi does a good job in converting the strings. It is also reasonably fast, but still not acceptable in a speed critical code. This was the problem in my employer's code base. We are thinking how to use UTF-8 for the core program without triggering many auto-conversions. One choice is to dump Delphi and use only FPC. Now the code still works with both. Juha P.S. I am still wondering why you are so fond of WinAPI while you have a nice cross-platform API available. -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
