On Sat, 22 Nov 2014 14:37:00 +0100 Jürgen Hestermann <[email protected]> wrote:
> Am 2014-11-20 um 17:21 schrieb Mattias Gaertner: > > The development version of FPC 2.7.1 has extended Strings and many RTL > > functions now work for codepages other than the system codepage. > .... > > 2. The new mode: The LCL, FCL and RTL treat all "String" as UTF-8 encoded. > ... > > When accessing the WinAPI you must use the W functions or use > > UTF8ToWinCP and WinCPToUTF8. > > Is this correct? > The W functions of the WinAPI expect UTF16 so > a conversion needs to be done in both cases, > either to System code page or to UTF16. > Or can we use STRING with WinAPI W functions directly? You can use them directly. For example: procedure TForm1.FormCreate(Sender: TObject); var s: string; // String = AnsiString because of $H+ begin s:=GetCommandLineW; // GetCommandLineW returns a UTF-16 PWideChar // the compiler adds code to convert this to the // default system codepage (CP_ACP = CP_UTF8) // the resulting string has StringCodePage CP_ACP // and is encoded in UTF-8. // therefore you can simply use it with the LCL Memo1.Lines.Add(s); end; You will get a compiler warning (id 4105), that WideString to Ansistring might loose data. The warning is right if the default string codepage is not UTF-8. If your code only runs with the RTL in UTF-8 mode, you can disable this warning. As alternative you can use: s:=UTF8Encode(GetCommandLineW); You must also use UTF8Encode if your code should run with both FPC 2.6.4 and 2.7.1. Mattias -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
