Recent

Author Topic: TCheckBox and TCheckBoxThemed both fire OnClick when they should not.  (Read 2421 times)

jamie

  • Hero Member
  • *****
  • Posts: 5011
It seems the Onclick of these controls fire when not in focus and having their state set by code.


In any case, setting the state by code should not be firing the OnClick, only user does that. Delphi documented.

simply toggle the check state via code with a button and monitor the OnClick, you will see it gets called each time.

Also, the controls should have a MODIFIED property that gets set to false when done by code and True when in focus and done by user.
 this is to determine in the OnChange event how it got set.
The only true wisdom is knowing you know nothing

wp

  • Hero Member
  • *****
  • Posts: 9012
Re: TCheckBox and TCheckBoxThemed both fire OnClick when they should not.
« Reply #1 on: October 11, 2021, 08:10:31 pm »
The same unlogical behaviour exists in Delphi's TCheckbox - therefore, it's difficult to change this...
Mainly Lazarus trunk / fpc 3.2.0 / all 32-bit on Win-10, but many more...

jamie

  • Hero Member
  • *****
  • Posts: 5011
Re: TCheckBox and TCheckBoxThemed both fire OnClick when they should not.
« Reply #2 on: October 11, 2021, 09:19:42 pm »
Oh really? I will need to check that myself but their docs state's it only happens a CLICK event takes place, and that is only user.

I don't have a recent running version of Delphi in front of me but  I do an older version which should be good enough to verify.


EDIT:
  I just check an older Delphi install and yes, it gets called there too, this shouldn't happen..

  Maybe we can at lease get a MODIFIED property added to know how the check state got set.
« Last Edit: October 11, 2021, 09:34:20 pm by jamie »
The only true wisdom is knowing you know nothing

wp

  • Hero Member
  • *****
  • Posts: 9012
Re: TCheckBox and TCheckBoxThemed both fire OnClick when they should not.
« Reply #3 on: October 11, 2021, 09:49:26 pm »
Just checked it with Delphi XE 10.3.3: a form with a Checkbox having an OnClick handler with writes an "OnClick" message to a memo, and a button with toggles the Checkbox.Checked state. Both ways of changing the Checked state - directly by clicking the checkbox, or by code after clicking the button - put the "OnClicked" message into the memo.

Similar to Lazarus which is even more unlogical because there is also an OnChange event which fires along with OnClick. Probably these two should be handled like in TListbox where they can be decoupled by unchecking the ClickOnSelChange property.
Mainly Lazarus trunk / fpc 3.2.0 / all 32-bit on Win-10, but many more...

jamie

  • Hero Member
  • *****
  • Posts: 5011
Re: TCheckBox and TCheckBoxThemed both fire OnClick when they should not.
« Reply #4 on: October 11, 2021, 10:33:52 pm »
Well I have an idea:
   If the OnChange handler is assigned then don't call the OnClick handler when check state is being set by code ?

 At least for those porting over D code if they don't use the OnChange event the OnClick will still be the same..

but if the user does interact with it then I guess both should be called like they are now.


EDIT:

  I got thinking about this, all that is really needed is a MODIFIED property like a few other controls have.

 This property needs to be set to False when ever the check state is changed by code and set to true when user makes changes.
 

 Also the Property needs to be public so that it can be cleared externally if needed before re-entry to the control or leave it in its last state for later review.


« Last Edit: October 11, 2021, 10:47:17 pm by jamie »
The only true wisdom is knowing you know nothing

wp

  • Hero Member
  • *****
  • Posts: 9012
Re: TCheckBox and TCheckBoxThemed both fire OnClick when they should not.
« Reply #5 on: October 11, 2021, 11:56:11 pm »
There's already a protected property, ClicksDisabled, inherited from TButtonControl. Its name is a bit misleading: clicks are working, but only the OnClick event is suppressed. However, it is too radical because OnClick does not fire now even when a real user-click occured - see attachment. But I think this could be adjusted.

In my opinion, OnChange should fire always when Checked changes. And OnClick should fire only when the user clicked. In addition,there should be a Delphi-compatible mode in which OnClick fires always.

Did not check it, but TRadiobutton probably has the same issues, as well as TToggleBox (they all inherit from TButtonControl)

Not sure about a Modified property. I'd expect to see this in Edit-like controls (TEdit, TMemo, TSynEdit), but not in every user-input-control. Following your argument, TRadiobutton, TRadioGroup, TCheckGroup, TListbox, TCombobox, TListView, TTreeView, TSpeedButton, TToolButton etc. should have it too - a LOT of work.
Mainly Lazarus trunk / fpc 3.2.0 / all 32-bit on Win-10, but many more...

Bart

  • Hero Member
  • *****
  • Posts: 4505
    • Bart en Mariska's Webstek
Re: TCheckBox and TCheckBoxThemed both fire OnClick when they should not.
« Reply #6 on: October 12, 2021, 07:04:12 pm »
I think the suggestion to introduce a property for this (no OnClick when changed by code) is the proper way to go.
The default behaviour should be as it is now (since that is Delphi compatible).

We've done similar things in the past (e.g. for TabControl IIRC).

(And, we should not merge this to 2.2 fixes, since it's basically a new feature.)

Bart

jamie

  • Hero Member
  • *****
  • Posts: 5011
Re: TCheckBox and TCheckBoxThemed both fire OnClick when they should not.
« Reply #7 on: October 12, 2021, 09:12:33 pm »
really..

 That only takes care of the Click handler but does not address who made the changes.


 When I suggested implementing the MODIFIED property it was to say that it would take care of both issues without even changing the current behavior of the CLICK, just leave it as it is now and no Delphi property has to be added.

 There for with the MODIFIED property a coder can simply test this value during a Onclick or Onchange, which ever one they wish to use and thus give them the info needed as to who and how it got there.

  On top of all that, when the control losses focus that value can be queried later for user actions in case more operations need to take place.

  Wouldn't it be better to have one minor change to solve two problems ?

  Currently I have to setup an array of flags in a form and set them ahead of time to False before initiating values, then in the handlers I need to check for this so I don't go back and make changes to something that are already the same value which leads unwanted side effects.

  Do as you please, i am just white noise here and I know how to work around it.





The only true wisdom is knowing you know nothing

 

TinyPortal © 2005-2018