I have an SWT Text and I want it to have Focus until the User Enters something.
Currently I´m using a FocusListener and check at focusLost Event, if the User has entered something. If not, I throw him back to the Text Field.
I think this is the wrong way as I don´t want anything to happen which I have to reverse then (e.g. if the user focuses another Part, I have to give focus back to the part with the Text and so on)
Does SWT provide me a way of blocking any other action but entering something into the SWT Text?
Like a Listener that gets triggered before the action happens and in which I can prevent the action to happen? Like a VerifyListener for every event type?
Related
I'm working on a small app for a class. One of the functions I want is when a button is clicked, it adds an object to an ArrayList based on the fields that they filled. When they click they button, I want them to have visual confirmation that the action has been performed. However, just updating a JLabel would cause it to sit there forever after the button was clicked.
I would like the label to start off displaying "".
When the button is clicked, I want it to say "Character Added!"
..for a few seconds. and then switch back to "".
I looked up some questions about label updating using a timer, but most of them have been using it to display a counting down clock, and they usually use a timer start method. I'm confused about if you need a timer stop method to reset the label.
Any pointers?
What I ended up doing is, instead of using a JLabel that updates, I simply made it so when the button is pressed and a character is added to the ArrayList, I called
JOptionPane.showMessageDialogue("Character Added!");
That way instead of a small little JLabel confirming it, they get a very apparent notification that requires them to acknowledge it. Tons more simple than doing the whole Timer thing.
I'm writing a program using JavaFX and I currently have three TextFields. When you press enter while any of the text fields are focused, there is an EventHandler which calls the appropriate method for each field. There is no submit button because I want it to submit each input separately (that's just how I made the rest of the program) to be validated and return a String containing any errors in the input. If the users input is invalid, it resets it to the last valid value it had.
However, when testing I found that sometimes I just click somewhere else (such as the next field) rather than pressing enter, so I wanted to implement the same function as pressing enter but when the user clicks outside the field. There is a MouseClicked event on the root that I have attempted to make it submit the input for all of the fields at once which works, but if any field has not been filled in, then it will be unsuccessful and return an error message (which might confuse a user).
Additionally, if the user clicks inside the TextField again, say to delete something from the middle of the word, the event will be triggered and the field will be reset to the last valid value if the current input was invalid.
I've considered using a MouseExited event on each field, but I think that might be triggered by the cursor leaving the field, rather than a click outside of the field.
What would be a good way of doing this, while minimising the number of event methods in my program?
I know there are many questions on how to focus on a certain text field and so on, but it seems that the issue I am facing is a bit different. So, I have a JTextField which has functionality to autocomplete the text if something that is currently in it has been typed before by the user. I also have a set of buttons that perform insertion of some predefined portion of text into the text field when pressed. The problem is that every time any new text appears in the text field, the autocomplete can trigger and append the text that was used by the user previously. In order to it more friendly, I decided to select the part appended by the autocomplete. All the code is executed in the ED thread. Consider the case when the text field was not in focus :
Both code samples are in the actionPerformed method of the button.
// does not work
if (textField.requestFocusInWindow()) {
textField.getDocument().insertString(...);
}
The insertString() is overriden and has all the logic to select appended string by the autocomplete. So, the only thing I need is that the text field is selected before the string is inserted.
I tried :
// does work
textField.requestFocusInWindow();
SwingUtilities.invokeLater(() -> {
textField.getDocument().insertString(...);
});
The official doc says :
The call to the requestFocusInWindow method initiates the focus transfer, but it does not immediately move the focus ...
This sort of makes sense, since to acquire the focus, a call must be made to the window manager of the clients operating system (that's how I understand that, correct me if I am wrong).
Is the second example working mainly because both events (getting focus and inserting the string) are added to the event queue and the insertion appears after the focus request (actually at the end of the queue) or am I missing something? Is it a valid solution? Can it be done better?
Note: simply adding a listener to the text field ( to react when it is in focus) is not a solution, since the logic I described here is only a part of the whole functionality used.
I have a MenuItem with a shortcut key to save the data of a JTextFied temporary and print it
The save function is called on FocusLost event of the JTextField and the print is called via MenuItems actionListener and is fired when I click on the MenuItem as well as when i press the shortcut key for the menuitem (eg: f1)
The problem is that when i directly press f1(shortcut for menuitem), the focusLost event for the Textfied is fired only after the menuitem has performed its action, whereas when I go to the menu and press, the focuslost is fired first followed by the menu's Action
Is there a way to force a Focuslost so that even with a shortcut key, the focusLost event is fired first
Tried using requesfocusinWindow, setText (performed on other demo textfields just to force a focusLost)
1) I think that's not possible in Programing Languages, more about that in the theory of AWT Focus Subsystem and How to Use the Focus Subsystem,
2) you have to redirect this Save Processes to the Backgroung Task, and before that you can check if JMenu and its JMenuItem are/aren't selected, for this check use only ButtonModel, otherwise don't do that, because your GUI heve to waiting for this processes
3) anothere choice is save on periodical bases values from JComponents to some Array, there you can check if value was/were changed, all changes must be checked/saved from Backgroung Task, without any impact to the Swing GUI
4) easiest way how to create something as Timer would be to wrap some logics to the Runnable#Thread, delayed by Thread.sleep(int) but exclusively inside Runnable#Thread only
It is generally suspect when you want to 'force' focusLost, as the intention of that event is the user did something to change the focus status of the application. When you say that F1 is a menu item shortcut, do you mean it is a shortcut to the same code that is executed when the menu is selected, or that you have it setup as a menu mnemonic?
In the end, shortcut keys do not generally change focus intrinsically, whereas the mouse actions required to click a menu item do, and that is something you may have to account for yourself.
I am working on a project that is using a JTable to display, among other things, a column of dates. We needed validation for the user input for dates, so I have implemented a combination of masking for format validation and parsing for actual date validation. I have done this using a custom CellEditor for the date column.
Inside my MaskedCellEditor, I have a JFormattedTextField. I setup the masking for dates. Then I add an InputVerifier to allow for actual validation. My InputVerifier implements verify() to check: 1. textField.isEditValid() 2. DateValidator.ValidDate(). If either is invalid, verify returns false and the InputVerifier locks the focus into the text field (the cell editor) and a small message dialog is displayed reminding the user of the date format.
The error message is a small, undecorated, non-modal, non-focusable JDialog that pops up underneath the cell being edited. It disappears on a keypress or a successful date verification. It is working great except for a small edge case.
If the user selects a menu button on the top of the application while an invalid edit has popped up the dialog, it switches screens, destroying everything currently on the screen (including the table). However, since the dialog is being shown and a keypress/successful edit has not occurred, the dialog is never hidden. It remains visible in a completely unrelated context on a different screen. Once the user has switched off the screen with the table, there is no way for the user to get rid of the dialog.
I have debated throwing either a Timer and/or a MouseListener on the dialog itself that would cause it to disappear, but I feel that I am ignoring the actual problem. The dialog is never being disposed of and I am pretty sure its because it is still set to be visible and it is preventing the garbage collector from getting rid of it.
I have a Cleanup method on the panel holding the JTable, but I cannot find a good way to reference the dialog (a component of the InputVerifier) in order to get rid of it. The dialog is pretty far removed from the table's parent panel. (Panel -> JTable -> CellEditor -> JFormattedTextField -> InputVerifier -> JDialog)
Any ideas on how to force the dialog to be hidden when the table is destroyed? If you need more details, let me know. I'm trying not to get you guys bogged down in the details, but there is a lot going on.
As a first thought, can you not go down the listener approach. If you have a closeErrorDialog() type method that gets called when upon successful valdiation, then you can also call it when a menu action is selected.
As an alternative, perhaps you could control the transition from menu to menu in some way, and create a "cleanup" method which will close down any exisiting error dialogs. This would allow for any other actions that need to take place when changing menus, to happen in the same place.
Just a couple of quick ideas of the top of my head. Hope they are along the lines of what you meant
Many people will vote me down for saying this, but it sounds like your dialog should be modal so that users can't switch away from it without dismissing it first. Or at least disable the menus that allow people to switch away while this dialog is displayed.