TCheckbox.Checked should trigger onClick?

[bdexterholland]

Should TCheckbox.Checked trigger OnClick?

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

1. unit Unit1;
2.  
3. {$mode objfpc}{$H+}
4.  
5. interface
6.  
7. uses
8.   Forms, Dialogs, StdCtrls;
9.  
10. type
11.  
12.   { TForm1 }
13.  
14.   TForm1 = class(TForm)
15.     Button1: TButton;
16.     CheckBox1: TCheckBox;
17.     procedure Button1Click(Sender: TObject);
18.     procedure CheckBox1Click(Sender: TObject);
19.   private
20.  
21.   public
22.  
23.   end;
24.  
25. var
26.   Form1: TForm1;
27.  
28. implementation
29.  
30. {$R *.lfm}
31.  
32. { TForm1 }
33.  
34. procedure TForm1.CheckBox1Click(Sender: TObject);
35. begin
36.   ShowMessage('hello! it''s that you''re looking for?');
37. end;
38.  
39. procedure TForm1.Button1Click(Sender: TObject);
40. begin
41.   CheckBox1.Checked := not CheckBox1.Checked;
42. end;
43.  
44. end.
45.  

[Zath]

For the record, Delphi 11.1 does it too.

So the action of it being ticked at runtime is regarded as a button click on the control even though it wasn't.
Interesting.

Lazarus does it with the radiobutton too.

[hamacker]

Lazarus 2.2.2 when change state (checkbox.state) does not trigger OnClick or OnChange, just when Checked:=[true/false].
I would prefer not trigger when change by checkbox.state, but maybe it´s not the same behavior of previous versions.


For comparation, Delphi trigger OnClick if you change state or change Checked:=[true/false].

[jamie]

The control needs a MODIFIED property like a few others to report if user caused the change .
 It reports true if user changed state, otherwise false if a software change.

The value remains when the control loses focus so query of controls can be  made for an file update etc.

[bdexterholland]

The control needs a MODIFIED property like a few others to report if user caused the change .
 It reports true if user changed state, otherwise false if a software change.

The value remains when the control loses focus so query of controls can be  made for an file update etc.

I confess I don't like that approach. It seems to me a gambiarra for a behavior that has been developed wrong because another also does wrong.

The clear example is that allowing you to change the field without clicking trigger a click event. But click does not occur in context.

[jamie]

The control needs a MODIFIED property like a few others to report if user caused the change .
 It reports true if user changed state, otherwise false if a software change.

The value remains when the control loses focus so query of controls can be  made for an file update etc.

I confess I don't like that approach. It seems to me a gambiarra for a behavior that has been developed wrong because another also does wrong.

The clear example is that allowing you to change the field without clicking trigger a click event. But click does not occur in context.

 You may not like it but, the GODS at the helm dictate that the LCL should reproduce all of Delphis Bugs.

 So all you have left is to use an extra feature of the control to work around that and that would be the "MODIFIED" property.

 Even Delphi has a couple of controls with that property just for the same reason.

[VTwin]

It seems weird to me, but apparently it is supposed to. ComboBox as well. I thought I found a bug in the Mac widget set, but I has informed by Dimitri that it was a bug if it did not fire. Implementation across widget sets seems inconsistent, but you need to expect it.

I have large preferences dialogs that have complex Get and Set routines. Prior to setting I set a global flag (fIsSetting) to make sure that setting a ComboBox in code does not trigger an undesired event.

[jamie]

I just went in and recompiled that Control with a MODIFIED property.

The DOChange(Var Msg) message LM_CHANGE; handler only gets called when user actually makes changes, otherwise a software change does not trigger this.

  In that event, I set the MODIFIED property to TRUE.

  I made a little change in the CHECKED property to clear the MODIFIED property since it appears using that does not trigger the LM_CHANGE handler.

 With this in mind, The control still behaves the same as it did before with the acceptation of that it now sets the MODIFIED property which can be viewed while in the OnClick or OnChange etc.

 This was just an experiment, but it seems to work and follows suite of other controls that uses this same approuch.

 Bye.

[Arioch]

Funny how you are into it too.

Hopefully there would be an opt-out via

class var TCustomCheckBox.VCL_OnClick_Emulation: boolean  (which is not a very nice name, and if something would come with better name - i am all ears).

Default however would be Delphi-compatibility which always was like this (VCL TCheckBox never had OnChange or OnEditingDone or similar)

There were strong opinions both for and against Delphi behaviour, so both ways would be implemented.

Preliminary green light was given at https://gitlab.com/freepascal.org/lazarus/lazarus/-/issues/39870#note_1092375512