This method doesn’t have a good name. It’s also called when loosing focus (via inputAttemptWhileModal).
Maybe it should be split in 2 methods:

  • textEditorReturnKeyPressed (only called when the return key is actually pressed)
  • validateTextEditorChange (that would be called after the former is called, and in inputAttemptWhileModal directly)

(same applies for textEditorEscapeKeyPressed )


I agree it should probably be called something like “commitTextEditorChanges”, but why split it into two?


Well, in my use case, when the Label goes into edit mode, I popup another component so the user can either use the other component or enter a textual representation of what he wants.
However, since the other component take focus on click event, I would have expected to be able to differentiate between the user really pressing “Return” in the text editor than from a focus lost event.

Anyway, for this specific use case, I’ve now found this method: Component::canModalEventBeSentToComponent() which does what I want, since I don’t get a focus lost anymore.


I think the behaviour of “return key” = commit change fits in 99% of the case, but there are still other case where it doesn’t (for example, think of a IP address input box, pressing “.” should validate the input box).
In all case, there is a semantically difference between “validation key pressed” and “commit change to label”.

One could use the former to actually modify the label’s text so that a specific format is set (like me, user type “34”, the text must become “34.00” when displayed), and call the second himself.
Anyway, with the setText fix from the other thread, and the modal hack from Component, I could do what I want for my specific use case.

When loosing focus, you actually intended “rollback change to label”, but not “validation key pressed”. (There is no need to go through the format validation again, in the previous example).