Ahh thanks for the post. I believe it was working for me in Beta 3, I'll check for clarification. Debugging it a bit, doesn't seem like this event is fired at a lower level of ValueBasedField, (Field<T>). Possible focus wonkiness here?
Well it does work in Beta 3, but there is an issue with focus and Enter. You can type whatever into the field and the event works fine, yet Enter is not captured, unless you mouse click the text field again (refocus).
Beta 4 doesn't capture Enter at all. Will try with Trunk SVN.
Yes, by "not working for me in Beta 3", I meant it wasn't usable for this usage, exactly for the scenario you describe (need to hit Enter twice with refocus). I was happy to see that keyPressed worked, but this one was broken too in Beta4.
This is occurring because of the default behaviour of GWT's AbstractInputCell and AbstractCell, from which our field cells inherit.
When a keydown, keyup, or keypress occurs on an element managed by a cell, the onBrowserEvent method is called on that cell. That method then calls its superclass's onBrowserEvent, which in turn calls that class's superclass's onBrowserEvent. This continues up the inheritance chain.
When AbstractCell.onBrowserEvent is called, it checks to see whether the event is a keydown and the key is Enter. When that occurs, it calls onEnterKeyDown. That method, implemented in AbstractInputCell, attempts to finish editing and blur the element (that is, remove editing focus). However, this means that by the time the Enter key is released, the element no longer has focus and the cell will not be receiving the keyup or keypress events.
As a workaround, you can subclass an Ext GWT field cell and override onEnterKeyDown to do nothing. This will prevent the cell from finishing editing and blurring, which means that keyup and keypress are fired. However, this also means that the value in that field will not be updated when a user presses Enter, and that the user will have to move focus away from the field by pressing tab or clicking outside the field for the value of that field to be updated.
Thanks for the detailed analysis. Looks like the bug should be filled at Google, instead...
I find strange that a default behavior, both in desktop applications, and in lot of Web applications, is so hard to implement properly. And the solution you suggest doesn't seem very satisfying either (as needing user interaction).
Somehow, the behavior I want on Enter is to move the focus to the form button marked as default (can be, traditionally, OK or even Cancel, can be some other button too, eg. Add) and action it.
Of course, it means that the controls are aware they are part of a form, so they can delegate the action to this form which in turn activates the default button. Not sure if that fits in the current GXT / GWT model.