On 2016-05-09 11:28, Jonas Maebe wrote: >> > so the programmer is completely helpless in preventing >> > this. > Unlike in previous FPC versions, in FPC 3.x the programmer can specify > the encoding that ansistring should use at run time via the > SetMultiByteConversionCodePage(). >
True, and from earlier mailing list discussions, not many know about that. No fault of yours of course. The most important point is that by the time they find out they need to call SetMultiByteConversionCodePage() they already lost valuable data. All the compiler does is raise "warnings" in the compiler output, yet happily compiles further and generates you a fatal executable. Those should really be errors! I'm not in the fpc-devel mailing list, but do you mind sharing some quick information on what the FPC team are planning for the RTL? I remember years back there was a discussion about two RTL versions (AnsiString and Unicodestring). Personally I think that would be a disaster to maintain. In FPC 3.0.0 there seems a hybrid mess (yes I understand the RTL is not Unicode ready, FPC 3.0.0 only made the compiler Unicode ready). My opinion: go the Delphi 2009 route and simply change the RTL to Unicodestring everywhere (or make a hybrid UTF8String & UnicodeString versions). If anybody wants the AnsiString or ShortString RTL's, stay with FPC 2.6.4 and maintain it yourself. Regards, Graeme -- fpGUI Toolkit - a cross-platform GUI toolkit using Free Pascal http://fpgui.sourceforge.net/ My public PGP key: http://tinyurl.com/graeme-pgp _______________________________________________ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
