Well the textchanged event should as far as i know call the event but there is no definition for this, i think xojo hasn’t made it clear but the event clearly tells you it’s raised on “text changed” so i would as you expect it to be the case.
Maybe best if xojo had a boolean parameter there TextChanged(byUser As boolean) where by user is true if one entered text in the field, otherwise this was from a .Text = “” assignment.
I tend to remember that not firing it was an intentional decision (as it happens too when changing these kind of properties on other controls), because the code setting the new value can take the needed action without firing the event itself from the own code.
Xojo coud have named the event UserChangedText then or something more picking. As the name suggests currently it’s raised when the Text is Changed so it sounds. We’ve been here before, but it’s becoming daily practice.
So basicly it’s always unclear what an event actually does “unless it’s clearly documented” which it’s not currenly.
Since the .Text is a property you can’t subclass to create your expected situation. (because shadowing properties are something you don’t want).
Historically throughout the framework it’s been that whether the value was changed by user action or code, the event would be raised. Some parts of Web 2.0 attempted to change this, but broke many user expectations and some of those parts have since been fixed.
To match with the functionality of controls like TextField and CheckBox, this behavior should be changed so that changing the value always raises the event. But that’s just me.
There’s always two schools of though on this. I was one of the people that pushed for “the event should only fire when the user makes a change” because that’s what makes sense to me. Regardless, there’s always someone who is going to need it to behave the other way, so here are the two options:
The event doesn’t fire on a programmatic change and if you want to have the same behavior, you put the code that needs to run into a method and call that method from the TextChanged event and from your code.
The event does fire on a programmatic change and if you want it not to do that, you set a flag before running your code, check the flag in the event and then unset the flag after your code runs.
either of these methods can be accomplished with a subclass of the control and its a pain if you have to subclass and modify every event of every control.
The other way would be to have Xojo a property either on the controls or possibly at the project level to allow the individual developers decide what they want.
While we can try to explain all issues here there is no solution which Einhugur for example has.
For example Einhugur’s CustomSwitch has this event:
Action(invokedByUser as Boolean)
It’s very clear what it does. If TextChanged had:
TextChanged(invokedByUser as Boolean)
This would cause an issue now, since the unexpected (in xojo terms) is now requiring a boolean check (breaking code)
Xojo could provide a solution to all these cases: TextChanged(invokedByProperty as Boolean)
Where as invokedByProperty is only required to be checked on the case where the property change caused the changed event. Not breaking code, just adding a parameter.
Do note that we all expect this to be and remain consistent on ALL of the same type controls wherever possible. Desktop, Web Etc.
Desktop and Web work the same, that’s TextField one way and SearchField a different way but both platforms are consistent.
What I understand from David’s comment:
TextField.TextChanged and SearchField.TextChanged can behave different as long as they work the same in Desktop, Web and Mobile
So I tested Desktop and Web and they work the same between them.
I hope is clear now that:
TextChanged events work different between controls (I don’t think this should happen)
TextChanged events work the same way (different) between Desktop and Web
Don’t worry if you still do not understand what I’m trying to say, I’m sorry is not clear. It has nothing to do with the real problem (different behaviour between controls that should not happen). As this is not exactly related to the original post and information posted to answer another user post, this is the last post from me about that.