Simple LiveBindings usage questions

[Andrew Spencer 2]

Using Delphi 11.3

I often have a situation where the .Visible property of a control depends on the .Checked property of a TCheckBox (or similar). To do this, I typically write an OnClick event for the TCheckBox, and set the .Visible property of the target control in a single line of code

e.g.

TargetLabel.Visible := SourceCheckBox.Checked;

I also make sure to call this OnClick event at startup, if I happen to need to load the .Checked state from a previously-saved registry or Ini file entry.

 

I thought that LiveBindings was designed to help me get rid of needing to write OnClick events. So to test I set up a TForm with a TLabel and a TCheckBox, with LiveBindings Designer as follows:

 

My expectation was that, from then on, the TLabel.Visible property will simply follow the state of the TCheckBox.Checked property. No additional code would need to be written.

 

BUT, it didn't work exactly as I expected.

 

Question 1 : When I run this, the TCheckBox.Checked property initialises to the Design-time setting of TLabel.Visible. Setting TCheckBox.Checked to True at Design-time is ignored. Why is it not the other way around i.e. The TCheckBox.Checked value, at Design-time, determines the TLabel.Visible property at Run-time? That's the way that the arrow is pointing. This only appears to happen AFTER the application is up and running i.e. clicking on the TCheckBox will alter the visibility of the TLabel accordingly.

 

Question 2 : How can I get this initialised, at run-time, so that the two controls start off operating correctly? I have only found that setting BOTH the TCheckBox.Checked AND the TLabel.Visible properties to the same value gets things going correctly.

 

Question 3 : Programatically changing the TCheckBox.Checked state at runtime does not cause the TLabel.Visible property to change.

 

Question 4 : Have I just totally misunderstood what I can do with LiveBindings, or how to implement what I want?

 

[corneliusdavid 214]

In the LiveBindings Designer, click on the arrow-line that connects the two components (the line will turn bold to indicate it's selected):

 

(Instead of visually selecting it, you can double-click the BindingsList component on the form and select the TLinkControlToProperty that connects these two components from the list of LiveBindings.)

 

Then in the Object Inspector for this link, check InitializeControlValue.

Edited March 13 by corneliusdavid
tried to delete duplicate image

[corneliusdavid 214]

I inadvertently included a second screenshot in my previous post--ignore that.

 

Also, I didn't thoroughly read the whole problem and my answer does not solve the problem, even after playing around with the combination of AutoActivate, InitializeControlValue, Managed, and Track properties of the binding.

[Serge_G 87]

It's been a long time since I've looked into livebindings, outside database links and even, less in VCL being much more FMX 🙄

So, this question caught my attention.

My first idea "its a VCL fact", but, writing the same sample in FMX, I got the same point 3 behaviour.

My second clue was to notify BindingList a change, in memory my firsts steps with livebindings 

procedure TForm1.Button1Click(Sender: TObject);
begin
Checkbox1.Checked:=not Checkbox1.Checked;
BindingsList1.Notify(Checkbox1,'checked');
end;

But, unsuccessfully. My guess, checkbox state is changed after the drawing ?

For that sort of, unusual, thing I used a one record ProtypeBindSource component with a boolean field

 

And this code
 

procedure TForm1.Button1Click(Sender: TObject);
begin
PrototypeBindSource1.DataGenerator.Fields.Items[0].SetTValue(not checkbox1.Checked);
end;

 

Project22.zip

Edited March 13 by Serge_G
added code sample

[PeterBelow 238]

On 3/12/2024 at 12:35 PM, Andrew Spencer said:

Using Delphi 11.3

I often have a situation where the .Visible property of a control depends on the .Checked property of a TCheckBox (or similar). To do this, I typically write an OnClick event for the TCheckBox, and set the .Visible property of the target control in a single line of code

e.g.

TargetLabel.Visible := SourceCheckBox.Checked;

I also make sure to call this OnClick event at startup, if I happen to need to load the .Checked state from a previously-saved registry or Ini file entry.

 

I thought that LiveBindings was designed to help me get rid of needing to write OnClick events. So to test I set up a TForm with a TLabel and a TCheckBox, with LiveBindings Designer as follows:

 

My expectation was that, from then on, the TLabel.Visible property will simply follow the state of the TCheckBox.Checked property. No additional code would need to be written.

 

BUT, it didn't work exactly as I expected.

 

Question 1 : When I run this, the TCheckBox.Checked property initialises to the Design-time setting of TLabel.Visible. Setting TCheckBox.Checked to True at Design-time is ignored. Why is it not the other way around i.e. The TCheckBox.Checked value, at Design-time, determines the TLabel.Visible property at Run-time? That's the way that the arrow is pointing. This only appears to happen AFTER the application is up and running i.e. clicking on the TCheckBox will alter the visibility of the TLabel accordingly.

 

Question 2 : How can I get this initialised, at run-time, so that the two controls start off operating correctly? I have only found that setting BOTH the TCheckBox.Checked AND the TLabel.Visible properties to the same value gets things going correctly.

 

Question 3 : Programatically changing the TCheckBox.Checked state at runtime does not cause the TLabel.Visible property to change.

 

Question 4 : Have I just totally misunderstood what I can do with LiveBindings, or how to implement what I want?

 

If this is for VCL: I centralize such code by overriding the UpdateActions method of the form and updating the control states from there. Much easier than fiddling with multiple event handlers or live bindings.

[Lars Fosdal 1791]

Personally, I shun LiveBindings. In my experience, they are slow and fragile.
Disclaimer: I haven't tried them since the version of Delphi when they first arrived.