Searchfield TextChanged not fired programmatically

The event “Text changed” is not triggered when text is changed by code in a DesktopSearchField.

Is this intentional or a bug?

With a “DesktopTextField”, however, the event is triggered when the text is changed by code.

macOS Ventura 13.2 - Xojo 2022 R4.1

Thanks for checking.

Did you try DesktopSearchField ?

Yes.

As I wrote: … when text is changed by code in a DesktopSearchField. :smile:

ah must have overlooked that somehow.

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.

Hi @Wolfgang_Meier

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).

2 Likes

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.

3 Likes

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:

  1. 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.
  2. 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.

That’s the .Net behavior, Xojo is distancing from what people are used to.

The event is called ‘TextChanged’ and should fire if the text is changed by the user, by code or whatever.

Xojo can add something like ‘TextChangedByUser’ if they want, that will only fire if the user change the text and not by code.

We should not have some TextChanged events fire if changed by code and others not fire (as it looks is happening now with TextField and SearchField). This is at least confusing.

1 Like

I just wanted consistency between Desktop, Web and Mobile, whichever was the model chosen.

It looks like both work the same (at least on Mac):

  • TextField.TextChanged fires if changed by User or Code
  • SearchField.TextChanged fires only if changed by User

For me, 2 decisions:

  1. Is there some “rational most adopted” behavior for such event, better by far, by the market for a similar event in that context? Let’s adopt it too.

  2. What is adopted, we should consistently reflect in all supported platforms.

1 Like

I don’t get it. You say they work the same and then list a mismatching behavior of 2 control.TextChanged()

Work the same Xojo Desktop and Web, that’s why I posted this:
image

TextChanged events should not work different even if they work the same in Desktop and Web (not all agree, so this is my opinion).

1 Like

That’s not the same. You pointed out an example of 2 controls behaving differently the same event.

1 Like

That seems to be the common case with xojo these days.

1 Like

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.

1 Like

Correct, language barrier, sorry about that.

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.

Regards

Nah. I’m ok with that kind of issue. Don’t need to apologize. In the past I had lots of small issues due to language and culture differences, you are not alone. :laughing:

1 Like