TWriter.WriteSingle() writes invalid value into *.lfm file

[Groffy]

Hello,

just testing a 3rd party component package with Lazarus trunk / fpc 3.0 and after placing a component onto a form, it writes a property value as Single into the *.lfm file by ending the line with a "s" char. Is that the way to mark the value as data type single?

When compiling the application an exception EReadError : Invalid value for property is thrown. With Lazarus 1.6 its working without any problems. Any changes in the TWriter class?


With best regards

[korba812]

Hello.
There are a few changes to the file lresources.pp:
http://bugs.freepascal.org/view.php?id=28040

But should be backward compatible. And is compatible with Delphi.

Can you provide a sample?

[Groffy]

I will try, but what might be the reason that the TWriter.WriteSingle() writes a "65s" into the *.lfm file?

[korba812]

Your code is correct and You did not have to provide an example. The problem lies in the methods TReader.ReadPropValue and TWriter.WriteProperty and new Lazarus functionality, that allows you to edit and save variant properties.(http://bugs.freepascal.org/view.php?id=30378)
Now some float values ar stored in LFM with letter at and.
Single values are saved with the 's' at end, currency with 'c' and date with 'd'.
Additionally, currency is stored as an integer (currency value * 10000).

[Groffy]

Single values are saved with the 's' at end

Ok, so the problem seems to be to read back the correct values with the TReader class

[Thaddy]

Now some float values ar stored in LFM with letter at and.
Single values are saved with the 's' at end, currency with 'c' and date with 'd'.
Additionally, currency is stored as an integer (currency value * 10000).

I have to check, but, really? That is a blatant design mistake. Those kind of info should be stored at negative offsets so the length and content can be considered opaque.
It also leads to these kind of problems and questions. This is meta-data. Meta-data describes a.o. what real data to expect. You do that beforehand.

That's a bug....

[edit some more]
I checked and indeed the info is stored at content end. That makes e.g. parsing difficult because the location of the payload description is not known beforehand and thus extremely inefficient.
That - see above - is not correct. Plz revert and do as I described/ suggest.

[korba812]

You're right. It seems that Delphi adds letter at the end only in variant type properties. I'll try fix it.

[Thaddy]

only in variant type properties.

That is equally evil: Even variants (maybe even specifically variants) should not be stored like that. Variants rely on meta-data complexity, more so than other types.

[korba812]

But in such a manner Delphi stores variant properties (attached example).
This is delphi dfm:

Code: Pascal  [Select][+][-]

1. object Form1: TForm1
2.   Left = 0
3.   Top = 0
4.   Caption = 'Form1'
5.   ClientHeight = 249
6.   ClientWidth = 418
7.   Color = clBtnFace
8.   Font.Charset = DEFAULT_CHARSET
9.   Font.Color = clWindowText
10.   Font.Height = -11
11.   Font.Name = 'Tahoma'
12.   Font.Style = []
13.   OldCreateOrder = False
14.   PixelsPerInch = 96
15.   TextHeight = 13
16.   object TestFloatVal1: TTestFloatVal
17.     SingleVal = 123.123001098632800000
18.     DoubleVal = 123.123000000000000000
19.     CurrencyVal = 123.123000000000000000
20.     DateTimeVal = 42370.523171296300000000
21.     VarCurrency = 1231230c
22.     VarDate = 42370.5231712963d
23.     VarSingle = 123.123001098633s
24.     VarDouble = 123.000000000000000000
25.     Left = 40
26.     Top = 32
27.   end
28. end
29.  

Now I can't reproduce this problem. Seems it works fine (letter is added only to variant properties).
Can you test it?

[Thaddy]

Delphi engineers can also make basic mistakes.
This is a basic mistake.
I wonder how that ever got through their quality control.

[korba812]

I do not think it was a mistake. If you look at TUTF8Parser.HandleNumber (lresources.pp), You see that even parser is prepared for that for some time.

[Groffy]

However it will be implemented, at least the TReader should be able to read the values which TWriter wrote without throwing an exception.

@Thaddy : What is your idea about storing data type Variant, how to store the data type information?

[Thaddy]

You store meta-data that describes what to expect before you store actual data.
The reason for that is that from the description in the meta-data you can choose the most efficient way to process the actual data.
So store a description first, then store the payload.
If you store meta-data at the end of the actual data you can not apply such a pattern.
You will have to read out all data and after that decide how to compute. That is not a very smart way to compute
That is a pretty generic design pattern or even design principle:
Store meta-data before the actual data itself.

[Thaddy]

I do not think it was a mistake. If you look at TUTF8Parser.HandleNumber (lresources.pp), You see that even parser is prepared for that for some time.

I beg to differ because of the explanation I gave above.
That something is already implemented in a certain way does not give any indication if it is implemented in the right way. Which it isn't...

I am merely explaining theory. That is also language independent.

E.g. I want to know if I am dealing with a telephone number (which I can't do much math with and can sub-sequentially be ignored) or a read out from some sensor....
Such a decision is based on meta-data info. See the point?

[korba812]

I understand that. But this applies to binary data without a defined format (as in the case of streaming binary objects for example via Treader / TWriter) when you should first read the type of data and then the data. LFM / DFM has a structure - one value per line, so if you want to read the value correctly, you need to process the entire line. Another thing is that the values are saved in decimal, so still you must first read the whole line to correctly convert to binary format.