|
|
|
|
|
Здымак экрана, 2018-11-16 22-44-14.png (18,812 bytes) |
|
|
Здымак экрана, 2018-11-16 22-56-36.png (23,745 bytes) |
|
|
Yes I can reproduce also with 'äö' found in my keyboard. As a workaround I recommend using "String" instead of "WideString". It would even be fully Delphi compatible. Why exactly do you want to use "WideString"? |
|
|
I need widestring to be fully Delphi compatible (lots of legacy). Btw - why cyrillic ($04**) and greek ($03**) works, but UTF16 ($00B0) that fits 8-bit does not? Form writer even writes widechar in delphi-compatible way item wi.ws = \0000955', '\0001085\0001084 end |
|
|
Then the problem must be in reading the streamed data. Widechar is written in delphi-compatible way, ok, but where is it read in? Is it in FPC's streaming libs? My debugging shows that TUnicodeStringPropertyEditor is used while editing the data. TWideStringPropertyEditor is not used but that is OK, they are about identical. > Btw - why cyrillic ($04**) and greek ($03**) works, but UTF16 ($00B0) that fits 8-bit does not? Good question, I don't know. |
|
|
|
|
|
laztest116.1.zip tests the FPC streaming on button click. ObjectBinaryToText does the exact dump as lazarus saves lfm see the dump1.txt ObjectTextToBinary properly restores binary data So the problem somewhere in Lazarus. |
|
|
dump1.txt (130 bytes) |
|
|
Lazarus uses its own text reader which in turn uses TUtf8Parser lresources.pas:5645 which does very brave assumption while reading widestring function TUTF8Parser.HandleDecimalString(var IsWideString: Boolean): string; if not TryStrToInt(Result,i) then i:=0; if i > 255 then begin Result:=UnicodeToUTF8(i); // widestring IsWideString:=true; end else if i > 127 then Result:=SysToUTF8(chr(i)) // windows codepage else Result:=chr(i); // ascii, does not happen Decimal string are always Delphi-like and should be considered as Wide Lazarus writes UTF8 as-is (using #-magic only for codes less than 0x20 - i.e. 0x9 0x0d 0x0a) This code effectively maps 128 - 255 UNICODE to windows single-byte code page |
|
|
lresources.diff (486 bytes) |
|
|
patch provided |
|
|
You have studied the code! I had no memory of where the relevant code is. Applied with minor modifications, thanks. Please check the related issue, too. |
|
|
in rev 18304 the widestring writing were fixed now the widestring reading is fixed. if there were some tests for LRSObject(TextToBinary|BinaryToText) for checking most corner cases in .lfm streaming these problem would be caught 9 (NINE) years ago. I think this patch resolves 0017746 I also try to check on MacOS/X, but - i'm sure this bug is platform-independent. |
|
|
MacOS/X tested |
- Anonymous
