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
