Hello,
I noticed that the Event OnRadioButtonClick does not fire if the Item is selected by code.
Here you can download an FMX windows project to reproduce the issue.
It is by design that for programmatically setting a value no event is triggered.
If you set a property by code, your code knows already about this change and no extra event is needed. It is superfluous. Events designed to signal code about user interface interactions. If code needs to be triggered when setting the property, your code can call this directly.
Please note that VCL standard RadioGroup does not work like you are saying.
Plus, the FNC CheckBox group works like I'm asking.
Please understand that we do not think that triggering an event for setting a property programmatically is needed.Again, if you set it in code, your code knows it is set and can act appropriately.
Hope you can change your mind and re-enter in the Standard, Aspected and consolidated way.
Best regards
We strive to have events triggered upon user-interface actions.
We think that events for programmatic changes are a useless detour.
The VCL itself isn't consistent in that respect.
The VCL itself isn't consistent in that respect.
For example:
OnChange only occurs in response to user actions. Changing the Text property programmatically does not trigger an OnChange event
I think you can agree with me that duplicate the code is never a good solution and that is always better to have a unique sure point where the code alway pass caused by an event. The way you purpose can create problems if I forget to do something when the standard solution does not. Anyway Sir do what you think is better.
Thanks for your time.
I agree that duplicate code is not a good solution. If you need the same handling of a radiogroup change from code as from UI, nothing prevents you from writing a 1 change handler and call that change handler from your radiogroup event handler and from the code that changes the radiogroup.
Finally, if a change in the radiogroup by code triggers the same event handler as a UI action, you not only have an extra detour for the code change, you can also no longer separate a UI invoked change versus a code invoked change. This is undesirable as such in several ways and a bad practice.
And yes, I am aware that in the VCL there are such implementations. I can only assume it are things remaining and not changed to avoid breaking backwards compatibility.
I hope this makes our viewpoint sufficiently clear and that we can close this discussion.
And yes, I am aware that in the VCL there are such implementations. I can only assume it are things remaining and not changed to avoid breaking backwards compatibility.
I hope this makes our viewpoint sufficiently clear and that we can close this discussion.