On Sat, Dec 9, 2017 at 1:41 AM, Werner Pamler via Lazarus <lazarus@lists.lazarus-ide.org> wrote: > Tested on Win32 where it fails in interfaces\win32\win32int because unit > "character" is not found. It is in rtl\objpas of fpc3.04, but not of fpc > 2.6.4, it came in with fpc 3.0.0
Damn, it is added by me. It is used only for function TCharacter.IsSurrogate(). Do you know a replacement function without copying the whole unit from FPC 3.0? LazUTF16 only has: function IsUTF16CharValid(AChar, ANextChar: WideChar): Boolean; A fix could be committed to the 1.8 fixes branch as a special case If no easy fix is found then I could add: if {$IF FPC_FULLVERSION<30000}False{$ELSE}TCharacter.IsSurrogate(WideChar(OrgCharCode)){$ENDIF} then and the code works with FPC 2.6.4 as it did before my changes. The call to TCharacter.IsSurrogate() fixes this issue only partly : https://bugs.freepascal.org/view.php?id=32101 UTF8KeyPress is still not called. Somebody with better knowledge of LCL-Win32 should fix it. On Sat, Dec 9, 2017 at 12:57 PM, Luca Olivetti via Lazarus <lazarus@lists.lazarus-ide.org> wrote: > I know I'll have to upgrade to fpc 3 someday, but what worries me about it > is my (and other 3rd party units) use of ansistrings as binary buffers. The automatic conversions by FPC 3 could indeed mess things up. However you should change such binary buffers to use TBytes or similar in any case. There have always been warnings against using String type for binary data. In future your code may use $mode DelphiUnicode and it breaks for sure. Maybe switching to FPC 3 is the right moment to fix the buffers, too. Juha -- _______________________________________________ Lazarus mailing list Lazarus@lists.lazarus-ide.org https://lists.lazarus-ide.org/listinfo/lazarus