TextInput on_change and validators working together

[cozimus]

In this minimum working example I tried to enable/disable a button based on a is_valid condition on a TextInput:

import toga
from toga.validators import Number

class MainApp(toga.App):
    def startup(self):
        self.main_window = toga.MainWindow(title=self.formal_name)
        self.button = toga.Button("submit")
        text_input = toga.TextInput(on_change=self.set_button, validators=[Number()])
        self.main_window.content = toga.Box(children=[text_input, self.button])
        self.main_window.show()

    def set_button(self, widget: toga.TextInput):
        self.button.enabled = widget.is_valid


def main():
    return MainApp("App", "com.example")


if __name__ == "__main__":
    main().main_loop()

My goal is to disable the button whenever the text is not valid.
However when I modify the text with a non-number value, the button is still enabled, and it is disabled only when I change again the text.
It seems like the on_change handle is triggered before the is_valid flag update, hence when I call my set_button functions, is_valid is still as the previous state.
Is it a feature or a bug? And what it would be a possible workaround?
The only thing I found was to define a custom validator, and inside that unable/disable the button:

def my_validator(self, input_string):
        try:
            float(input_string)
            self.button.enabled = True
            return None
        except ValueError:
            self.button.enabled = False
            return "Input should be an integer"

[freakboy3742]

That's an interesting problem. The evaluation of validation after the change signal isn't an explicitly intentional feature, but it is consistently implemented that way across all platforms (e.g., here's the macOS implementation - the same pattern is used on every backend.)

I agree that it would make sense for the "is valid" indicator to be correct when the change handler is invoked - you've identified at least one obvious use case; and I can't think of any use case that is made possible by the current behavior. I'll open a ticket for this feature request.

As an immediate workaround, you could invoke the validation logic as the first thing done by the on-change handler - (i.e., widget._validate()). That's not a public API, but it is the entry point used by all backends, so it should be reasonably safe.

[cozimus]

The only use made possible by the current behavior is that: if the text is changed inside the on_change function, the validator will take the new value. On the opposite, with such a new implementation, it will be validated only the user input value, but not the following changes. Although I don't know if that would be a problem or not...

About your workaround: there is a reason why a .validate() method is not implemented? In my opinion the best solution would be to keep the current implementation, adding a validate method to force the validation and notify this behavior in the documentation.

[freakboy3742]

Except that changing the value in on_change will trigger another change event (and another call to on_change), which will cause another validation.

If anything, validating before calling on_change removes a source of ambiguity; with the existing order, changing the value in on_change means there is an outstanding second on_change, which will cause a second validation call, but both of them will run on the second value (assuming the second on_change doesn't also change the value... there's definitely potential for an event cascade here). By validating before the call to on_change, the value being validated will always be consistent with the value being passed to on_change.

[cozimus]

Now that you point out, you are definitively right, I probably lost myself inside the on_change chain :). Hoping my question will help someone who will face the same problem...