| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0034561 | Lazarus | IDE | public | 2018-11-16 20:58 | 2018-11-19 19:00 |
| Reporter | Anton Kavalenka | Assigned To | Juha Manninen | ||
| Priority | normal | Severity | minor | Reproducibility | have not tried |
| Status | closed | Resolution | fixed | ||
| Platform | x86_64-linux | OS | Debian | OS Version | |
| Product Version | 2.1 (SVN) | Product Build | |||
| Target Version | Fixed in Version | ||||
| Summary | 0034561: propedit: Strange handling of symbol "°" - degree sign in collection item with widestring property | ||||
| Description | Symbol "°" stored in lfm as 0000176 cannot be read back. | ||||
| Steps To Reproduce | Install attached component package testpack.lpk Try to edit one of the collection items widestring property - for instance enter: "Т, °C" Save the form, close unit1 - then open again. Compare widestring property content (see the attached picture). Another collection item with both cyrillic and greek symbols (λ, нм) (upper byte of widechar set to nonzero) storerd/restored properly. | ||||
| Tags | No tags attached. | ||||
| Fixed in Revision | r59586 | ||||
| LazTarget | - | ||||
| Widgetset | GTK 2 | ||||
| Attached Files |
| ||||
|
|
laztest116.zip (67,313 bytes) |
|
|
Здымак экрана, 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 (67,843 bytes) |
|
|
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 |
