ConvertUTF8ToUTF16 is used now with LCL + FPC 2.6.x. I don't think it will be needed any more in the new system. (but not sure)
I just have been surprised to find "native" conversion functions (ConvertUTF8ToUTF16 and ConvertUTF16ToUTF8). Until now, I though there was just like UTF8ToSys for the ANSI API set - based upon a Free Pascal function (Utf8ToAnsi for UTF8ToSys), or now using the "magic automatic" conversion coming with Free Pascal 3.0+.
Then what is "xxx"?
1250
But is is really THE solution ?
I mean, this is only changing the dynamic code page value. One could -falsely- interpret this as having a string with 1250 as a code page : which is only
temporarily true.
Thing for which I've already given a sample in this post:
http://forum.lazarus.freepascal.org/index.php/topic,28941.msg182057.html#msg182057 (last part of the post, code and result).
May be a few reflexion before any changes would be interesting, especially a few others opinions, no ? (this is only my own opinion).
So there is a conversion going inside in the LCL from UTF8 <> UTF16? How often are these conversions?
everytime you talk to any windows api.
May I amend a little bit your answer, if you don't mind:
[everytime you talk to any windows api,] when text is involved in the API (parameters or result; PChar, PWideChar....);
And I m' not trying to say it represents just a small -or a big- part of all the API calls in the LCL, because I just don't know how much.
I don't even have an estimation: some tests for getting the average values of the overhead would be quite interesting (I'd liked to see them, if anyone has some ...).
I am not sure of the time scale but as long as I know LCL has been UTF-8 only.
So I am. I've always seen these conversions UTF8<->Ansi API and/or UTF8<->Wide API in the LCL code (at least since a few years).
(edited)