highlighted OK button in 'Annimate at runtime ...' menu item does not work.
This bug is reported by a scientist user.
Under tools select 'Annimate at runtime...', it will ask you to for the 'Time to hold the highlight'. Enter a number. The OK button will be highlit, but you have to click on it or use 'Tab' firstly to select, even though it is highlit as opposed to simply hitting the 'Enter' (<cr>) button.
Haven't found other menu items having the same behavior.
In File --> Save As, you can just type file name and use 'Enter' to finish saving, no 'Tab' or mouse needed. I also tried the similar situations in other software, they allows users to just hit 'Enter' after enter number or string.
#4 Updated by Christopher Brooks over 9 years ago
Just to be clear, the problem here is that when a dialog comes up and the
user immediately hits the "Return/Enter" key, then the expected behavior
is that the highlighted button (usually "OK") will be activated and
the window will close. This is not the case with a bunch of Ptolemy dialogs,
the user must move the focus (either with the mouse or by tabbing)
to the buttons and then hit "Return/Enter"
I think the problem is with ptolemy.gui.ComponentDialog.
I attached three test cases.
The first one:
uses JOptionPane. It has a text entry field and when the user
hits return, the window closes.
The second one uses ptolemy.gui.Query and ptolemy.gui.ComponentDialog
does not close when the user hits return.
However, in the second attachment, if I comment out the Java code that
adds the line entry then code works as expected - hitting return closes
I suspect the problem has to do with focus and the focus of the internal
ptolemy.gui.Query not being passed up to the container ComponentDialog.
In Ptolemy Vergil, File | Save As uses the JFileChooser in ptolemy.gui.Top.
ComponentDialog is not used.
The third attachment:
embeds a JFileChooser into a ComponentDialog. This test does work, hitting
return closes the window. I think the issue is that there is not a
entry widget in the JFileChooser.
It could be that not having the focus be on the buttons is the right thing
in the case of the the second attachment. For example, if there was a
TextArea to be filled in and the focus was in the TextArea and the user
typed a return, then I'd expect that the TextArea would get the return not
the button. To try this, add
query.addTextArea("textArea", "An area", "Elvis");
to the second attachment.