TSpinEdit Fires OnChange when it shouldn't!

[jamie]

I thought this issue was resolved long ago ? Maybe it snuck in there for what ever reason?

When Setting the value program code wise the onChange Event should not be firing!

 This event should only fire when the user actually interacts with the control not when the coder changes the value in the background. This makes it difficult to synchronize two spin edits, one used for a low and the other as a high limit where if the low value exceeds the high then you need to adjust the high one etc.

  Through code this should be easy to manage, change the values of each control but don't expect the events to fire and if you need the event code to be executed then you can simply call the code method directly while you are there. But this isn't how it's working now, the OnChange files both ways when it should only be doing it from user interactions.

 I wrote a hack to get around it but this should be addressed.

 I suppose I can fix this myself but from what I've been seeing not much has been accepted from my end.

[Bart]

Isn't that in the bugtracker?

Bart

[wp]

When Setting the value program code wise the onChange Event should not be firing!

 This event should only fire when the user actually interacts with the control not when the coder changes the value in the background.

The LCL is very inconsistent here. Sometimes OnChange is triggered by user-interaction only, sometimes also by code, sometimes OnClick does the same as OnChange, sometimes OnChange refers to non-content changes only, etc. But the problem is: these have been there all the time, and many user programs have found a way around these inconsistencies. Changing this behavior will break numerous user programs out there.

BTW: I tested with the current Delphi XE10.3 - it also fires OnChange when the SpinEdit.Value is set by code.

[jamie]

I appreciate the attention my recent post are getting, it gives me a vote of confidence that people are actually taking notice, thank you very much for that. 

 I don't have a recent copy of Delphi so I can't test against it but it's obvious a crutch if it does it there, too.

 I believe I can mod the control with an optional flag allowing the coder to  make their choices.

 Options :[seNoOnChangeViaCode] or something of that line.

 I also noticed that EditingDone is confusing because I don't think it triggers the OnChange if the values are different? I'll have to look into that one..

 I'll get back to this one later, for now he hack I did is working for the time being but it isn't pretty .

[Bart]

IIRC then changing value by code makes the OS send a CM_CHANGE (?) event to which we react.
It may not always be possible to determine wether the WS notification is triggered by ourselfs setting it by code...

Bart

[jamie]

In windows there is a message "EM_SETMODIFY" you can send afterwards to remove the modified flag of the control. This flag is set when ever the text in the control gets modified in any way so if this message is sent after a change is done, it should null the response message.

 I guess I could test for this.

 Also, I don't know if this would be cross platform ether ?

[jamie]

Forget it, it seems that message does not give us anything to work with however, I did find that using a background variable to indicate code changes works to skip the OnChange call and then clear it afterwards.