On Fri, 8 Nov 2024 00:35:10 GMT, Martin Fox <m...@openjdk.org> wrote:
> > The failing `SpinnerTest::testEnterEscapeKeysWithDefaultCancelButtons` test > > is a bit odd; it expects that Enter in an **editable** Spinner should > > result in activating the Default Button. However, a normal TextField > > doesn't do this either... > > Maybe I'm misunderstanding this comment but in my testing pressing Enter in > an editable TextField can activate the default button as long as the > TextField doesn't have an OnAction handler set. It should not be so easy to > block Enter from activating the default button. Ah, perhaps that's the problem, I did have an action handler, although it did't consume the event (which normally should mean it's a no-op). Hm... > It might be helpful to write up a single test that verifies that Enter is > handled correctly for TextField, ComboBox, DatePicker, and Spinner. I'm > working on a PR to clean up ESC handling and it was useful to write up a > single test covering all of these controls. (I want to ensure that the user > can always uses ESC to close a modal dialog even if the TextField has a > formatter assigned to it. This isn't working currently.) Yeah, I guess I didn't look deep enough. > > Why doesn't Spinner work the same as ComboBox? For a ComboBox the client > registers the action handler directly on the ComboBox instead of the combo > box's editor. Very good point; when I was looking at the code I was quite confused with the way the editor property works -- it being read only seemed quite useless, except if that's the only way to register an action handler. It looks suspiciously like a poor design. ------------- PR Comment: https://git.openjdk.org/jfx/pull/1629#issuecomment-2463704866
