Order of initializing variables in controls on a form.

[Birger52]

Hope someone can solve this.

I have a control, that i have derived from a TPanel.
basically it holds an integer, that can be changed a.o. by mouseclicks and scrollwheel.

It has a maxnumber and a minnumber, and when number is changed, it is checked against these - and corrected if outside the range.

And it functions as it should.
It does not start correct however.
Default values are 0 for everything. These are set in the constructor of the control.
I change them at designtime, to what I need them to be - including a startpoint of the number- usually somewhere in the middle of the allowed interval.
But running the program, the number ALWAYS turns up as 0 - even when it is set to something else at designtime.
When running program, the moment I try to change the number, it immediately changes to min (or max).

Looking in .lfm file, everything is fine - except that number is 0, also when it is something else in Object inspector in Lazarus.
When I save project and opens it again, the number is changed to 0 (in object inspector), no matter what it was before.

So it seems the procedure that actually loads these numbers, changes them. (Before the TForm.Loaded() procedure)
The only thing I can figure, is that it tries to set the number, before setting the min and max - this will change the number to be 0, as default for max and min are 0.
How do I change the order of this, sp the number is set after min and max limits?

[Birger52]

Changed the order of declarations of properties in the control.
Recompiled.
Recompiled Lazarus (installed changed component)
Thru away .lfm file and recompiled project.
New .lfm file have values in the same order, as defined in the component, and apparently also sets values in that order, so number is now set after limitations (min and max), and thus not changed from value set at designtime.

Should say somewhere in tutorials, that the order of properties is important.

[devEric69]

I don't understand everything about your problem.

But (when we don't dynamically create the components at runtime):
- the properties of the other sister controls and their parent and owning TForm, can't be known for sure in their Constructor...
- ... hence, the rule that says that every time you have to make a reference to a property, of a sibling control or of its parent and owning TForm, it must be coded in their Loaded method (each control Loaded method is called after everything has been entirely built, the TForm and its components).

Another thing: a TCalculatedField and its Ffields \ properties, must be declared and created "statically" (TDataset "creation order" dialog) in its TDatamodule, before the other TFields it uses in its calculations.

[Birger52]

Properties and their values...
This is how I have understood things to function:
You can give a default value in declaration.
This doesn't mean, their value is actually set - on the contrary actually. It only means the value will not be saved in .lfm, if it is the same as the default value. (Mechanism to minimize .lfm files)
The property must be given a (the default) value in the constructor for the control - even if you don't give a default value in the definition of the property. This will be the initial value in the Object inspector at designtime.
Anything you set in the Loaded procedure, happens after values read and assigned from .lfm - and as such, values assigned in Loaded() overwrites values set at designtime.
Order of events is Create - set values from .lfm - Loaded.

My problem - or what I didn't know, and can't find in documentation - is that the order of properties of a control placed on a form, is the same as the order in which they are defined.

I have 3 variables (more actually, but ...)
A value, a min and a max.

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

1.     property Number : integer read FNumber write SetNumber;
2.     property NumMax : integer read FNumMax write FNumMax;
3.     property NumMin : integer read FNumMin write FNumMin;

Note that write for Number is a function - it corrects the Number, so it is within the limits given by NumMax and NumMin. (And it funcitons at designtime as well).
So when reading value from lfm, program reads Number first, and sets it.
The numbers for max and min, are not set yet, tho, so they are 0s.
Meaning, that no matter what value you set at designtime, it will be corrected to be 0 when the value set at desingtime is loaded from .lfm.
After that, the loader will read and write values for Min and Max - but this will not restore the original number to what it was at designtime.

So if you need a number between 5 and 15, you set these values as min and max, and set number to 10 at designtime.
When loaded, they are all 0 (set in constructor of the control). Then Loader sets Number to 10. And since both Min and Max are 0, this is changed to 0. Then Min and Max are loaded and assigned - and the result is, that the Number is 0 - outside it's permitted range.

I changed the order, so the number is loaded and assigned as the last one.
It is mentioned nowhere in documentation (that I have come across), that the order of the declaration of properties is the same order they will be set at runtime.
It may be logical (off hand the reverse order would make more sense - assuming important values are the ones, defined first), that there is a order - the loading procedure is not intuitive, and can't determine a logical order by itself.