Missing Properties in .LFM when value 0

[SandyG]

Came across an interesting bug I think (could be me not doing something correct).

Windows 11, Laz 3.0 (3-29-2024 build) FPC 3.22

Here is the issue...

I have a component that has various properties, when any of the properties that has a type of 'single' is set to 0 in the design time properties for a this visual component it does not appear in the .lfm file.

Screen shot attached.

In this case the MinValue is -10 and the MaxValue is 0, and the file now removed the MaxValue propert from it. Same if I change the MinValue to 0 and MaxValue to 360, the MinValue drops out of the file and MaxValue appears.

What then happens is that since this is not loaded, the value from the constructor is used and not set from the load of the .lfm (hope that makes sense).

Code for the property MinValue/MaxValue

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

1.         property MinValue : Single read FMinValue write SetMinValue;
2.         property MaxValue : Single read FMaxValue write SetMaxValue;

Might be something subtle that needs to be done with 'single' floating point types but didn't find much searching the forums.

Sandy

[paweld]

This is not a bug - it is a conscious behavior of the IDE. Default property values are not saved in lfm files - only values that are different from the default are saved

[SandyG]

That might make sense, but values for integer and byte are saved as 0 in the .lfm, why would a single be different?

Again this poses an issue where the loaded property value is not there and incorrectly set since the property inspector clearly shows 0, but the value is set to the default constructor value and not set when the .lfm is loading all the other properties.

Should I just remove the default values in the constructor to solve the problem (Not sure of the correct way to solve this), but don't like the idea removing the values, but might just be the right thing to do since they should default to zero when the .lfm is loading those values????

Sandy

[Thaddy]

That might make sense, but values for integer and byte are saved as 0 in the .lfm, why would a single be different?

That is because a floating point value is always an approximation - can be exact - whereas integer types are exact.

[SandyG]

Doesn't explain why the float would not be written as 0, the integer and byte are written, more so the float should be if not exact, but I think we are talking about a different issue. I recall (could be wrong) but zero in floating point can be represented exactly.

Experimenting when the value was something like 0.0000001 would write, but 0 would not. Just to be on the same page. Writing of the 0 is desired but not done in the lfm

The main thing (aside from all that) is to understand and hope to initialize a component value when the default value is not written to the .lfm, and my guess is to just remove the default value I have set in the constructor of the component. Again I don't know if this is the prescribed way of handling this odd situation but it might be - Seeking Guidance!

I don't see much value in removing the default value from the .lfm unless it is to really reduce size of the file and help with load time, but I think that is stuff left over from slow computers, might be other reasons

Sandy

That might make sense, but values for integer and byte are saved as 0 in the .lfm, why would a single be different?

That is because a floating point value is always an approximation - can be exact - whereas integer types are exact.

[Bart]

IIRC You can declare the property with stored true, to force the IDE to store the property, even if it has the default value?

Bart

[SandyG]

I will give this a try, it would be exactly what's needed in this case!

Thanks

Sandy

IIRC You can declare the property with stored true, to force the IDE to store the property, even if it has the default value?

Bart

[Remy Lebeau]

IIRC You can declare the property with stored true, to force the IDE to store the property, even if it has the default value?

You should also provide a default value in the property's declaration if you are initializing the property to a non-zero value in the constructor.

[SandyG]

Not exactly sure how to do this, looked for an example but didn't see one.

Thanks being said when I declared the properties like this

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

1.         property MinValue : Single read FMinValue write SetMinValue nodefault;
2.         property MaxValue : Single read FMaxValue write SetMaxValue nodefault;
3.  

The properties show up correctly even if set to 0 unlike before.

Would also like to see how you do it just in case what I did is not really a good way to do it.

Thanks

Sandy

IIRC You can declare the property with stored true, to force the IDE to store the property, even if it has the default value?

You should also provide a default value in the property's declaration if you are initializing the property to a non-zero value in the constructor.

[SandyG]

OK, tried the setting the property with a default value as suggested, and that works as well.

So the difference seems to be this,

If I set the property to 'nodefault' it will always write a value to the .lfm, not need to specify a default in my case as the constructor (create) has the default values so they get set if the design time values do not come from the .lfm

If I set the property to 'default' it will always write the value to the .lfm, but I need to set the default value in the property section of code instead of the Create method.

Hopefully this sounds right. Not sure which is better but I prefer to keep all the initializers in the Create, and use the 'nodefault' option but how do others handle this??

Thanks for all the help and feedback on this.

Sandy

[Remy Lebeau]

If I set the property to 'nodefault' it will always write a value to the .lfm, not need to specify a default in my case as the constructor (create) has the default values so they get set if the design time values do not come from the .lfm

Yes, unless stored is specified and it returns False.

If I set the property to 'default' it will always write the value to the .lfm, but I need to set the default value in the property section of code instead of the Create method.

This is not correct.  The default value you specify in the property declaration needs to match the value you assign in the constructor.  A property value is written to the LFM only if it contains a non-default value, unless nodefault is specified.  The constructor determines the actual default value when the code is executed, while the property declaration produces the RTTI needed to write the LFM.

Not sure which is better but I prefer to keep all the initializers in the Create, and use the 'nodefault' option but how do others handle this??

You really should not specify nodefault in most cases, unless you really want 0s in the LFM.  The idea is to keep the LFM as compact as possible.

See:

https://www.freepascal.org/docs-html/current/ref/refse41.html#refsu38.html
https://www.freepascal.org/docs-html/current/ref/refsu38.html#x92-1160006.7.6

Also consider reading Delphi's documentation, since LFMs have very similar semantics to DFMs:

https://docwiki.embarcadero.com/RADStudio/en/Creating_properties_Index

[SandyG]

@Remy -

Thank you the lightbulb just went on with specifying the default value and the storage modes default to True. I had looked at the pages you sent and it finally made sense.

I think in my case I'm going to go with the nodefault. Those values are more often specified so not much savings in always having the 0 value written. Personally I like that way better and I can't imagine much performance loss if that's the main reason this scheme was create for as it's only 2 or 3 props that have this, and again they mostly will be written with a value, and not 0.

Also helps me debug when I run into a problem of where some values come from if I explicitly see them in the .lfm 

Still 'warming up' with Lazarus and Freepascal, been a long long time since I did any work with it. And I'll honestly admit I worked for Borland many many years ago, but focused more on C++ and Java.

Very much appreciate everyone here taking the time to help!!  Now to fix up a couple of PR's in Git which is another source of my learning!

Sandy