Just wondering what focus means in java code, because I have seen onWindowFocusChanged, addFocussables, findFocus...
If I have a scrollable list and I scrolled it down, the first item will have focus false? or it means other thing?
Thanks
Focus means you have selected the particular GUI element. For example when you select a window that window gains focus, when you select another window the first window loses focus.... It's the same for JTextField, JTextArea, etc.
The definition of the focus here on StackOverflow is as follows:
Focus indicates the component of the graphical user interface which is
currently selected to receive input.
Saying that focused component is selected is not accurate. For instance, we can have a JCheckBox which is deselected (has no tick mark) and it is also the current focus owner. Since it has focus, its state is toggled with the spacebar. The term active is more precise. I came up with the following definition of focus:
Focus is a state of a component in which it receives keyboard input. Focus is represented by some visual cue; for instance, in Metal look and feel a focused JButton has a blue rectangle around its label. The component with the current input focus is called the focus owner.
The current GUI element that is "active" has the focus. For example when you have several Input windows only one can have the focus and receive your keyboard input. See here the Android GUI doc http://developer.android.com/guide/topics/ui/ui-events.html
Related
I'm working on a (legacy) Java-Swing application and ran into a problem:
The main GUI-component in this application is a Gantt chart, that displays tasks, as rectangles with a label, basically.
A right-click on a task opens a context-menu, while hovering over a task with the mouse will show a customized, scrollable JTooltip. This constellation leads to my problem.
If I position the tool-tip too far away from the current mouse position, the tool-tip disappears, before I can move the mouse to one of the scroll-bar handles (horizontal/vertical).
If I position the tool-tip too near to the current mouse position, the context menu won't open anymore, because the tool-tip hides the underlying task and the right-click is therefore captured by the tool-tip and not the task.
What I've tried so far:
searched for some kind of delay in ToolTipManager, to control how long the tool-tip is shown, after the mouse leaves the control, which triggered the tool-tip to be shown. As far as I can say, there is no such delay-property.
tried to find the right distance between tool-tip and current mouse position, so that the scroll-bar handles of the tool-tip can be reached and the context-menu is also shown. -> I found some distance, where both works, but often you have to try several times, until one can reach the scroll-bar handles.
So my question is:
Is there any way to control when a JToolTip is hidden after the mouse leaves the corresponding component?
create JWindow, better undecorated JDialog with correct modality (then could be easiest to catch MouseEvents)
only one window with setDefaultCloseOperation-DO_NOTHING_ON_CLOSE or HIDE_ON_CLOSE, by toggling only with setVisible false / true, to reuse this container for whole JVM instance, clear windows content before is setVisible(false) called
put there Swing Timer with (for example) 5-10 seconds for logical autoclosing, by testing SwingTimer.isRunning, if Mouse Scrolling continues and SwingTimer.isRunning returns true then to call SwingTimer.restart
override mouseClicked for whole JVM instance e.g.
if (window.isVisible)
window.getContentPane.removeAll()
window.setVisible(false)
else
someThingWithRealEventFromMouseListener
there can be used some of better Listener that returns Boolean value instead of using low level instance of MouseListener
you can to (re)dispatch() mouse scrolling (only inside of Bound of the current parent - JFrame, JDialog) to the popup window, by using two - three methods from SwingUtilities
I use a c1.setFocusable(false) so that my Checkbox c1 is not focused as shown in the pic and after that, focus goes to the next Checkbox c2, I use again c2.setFocusable(false) and it continues to all Checkboxes. Even if it doesn't find one, it continues to the next JTextField. Is there a way to not let the focus go to something instead of setting focusable to all my numerous components?
how can I get rid of that grey border thing?
Why would you want to do that? That "grey border thing" is the focus indicator. It is used to provide information to the user so the user knows which component has focus.
If you really want to confuse the user and make them guess which component has focus then you can use:
button.setFocusPainted( false );
I have a JFrame which contains most everything in the application. It has a KeyListener attached, and it also has several buttons and textfield on it. The problem it, when a button is clicked or a textfield is selected, it gets focus and shortcuts don't work. Of course, one can tab out of them, but to do this you must tab through EVERYTHING (each button, each textfield) before giving the window focus again.
Is there a sensible way to only require one tab to return focus to the frame from the textfield, and no tabs to return focus to the frame from a button click?
A WindowListener doesn't seem like the best way to do this, but if it's the only way I suppose I can forge forward there.
Thanks in advance!
It has a KeyboardListener attached
I have never heard of the KeyboardListener class so I can only guess what you are trying to do.
My guess is that you should NOT be using a listener of any kind.
Instead you should be using Key Bindings.
If you only need this for the textfield, you can add a keyListener to the textfield and when the user presses tab use yourJFrame.requestFocus(). Otherwise refer you may want to use a window manager or a key map.
i want to have some composite-wide keyboard-shortcuts. The composites in question are in a tab-folder. I have a little function, which traverses all children of my composite and adds a KeyboardAdapter to every one of them.
The problem I have is that, when I open on of the tabs pressed keys aren't registered. I first have set the focus on some selectable widget in the tab, then it works. When i switch to another tab and then back, the focus is still kind of there (a grey selection instead of a blue one in a table for example), but it, again, doesn't work, until i click somewhere.
How can I do this? I thought about adding a filter to my display, but i only want events in a certain composite (and everything in there).
Thank you
Key events are delivered to the component that has keyboard focus. Composites do not get the keyboard focus, it is usually one of their child components that gets it and then they start receiving the key events (in case they are not used by children). Having the key listener on the parent Shell may possibly work.
Some background:
I have a turn based game where you can play several concurrent games in separate windows. Each window/game has it's own chat and also a kind of game action panel that turns up when it's your turn to act.
The issue:
Game windows will steal focus whenever it becomes your turn to act in any of the games you're playing, this is by design but very annoying if you're involved in chatting at any of your games because when focus is lost that chat will no longer receive your key board strokes.
What I want:
Some way to dispatch key board events to a JTextField that's no longer the focus owner (and also in a different window/JFrame than the current focus owner). Is there some way to do this? And how?
Plan b would be to set some kind of timer on the chat and let the window refuse to give up focus until x amount of time has passed since the last key stroke in the chat, but it might not be ok to stall the focus switch since your action time is limited already.
You can set alwaysOnTop of the current chat window true while there's text in the chat text field by calling:
java.awt.Window
public final void setAlwaysOnTop(boolean alwaysOnTop)
throws SecurityException
When user presses Enter or clicks on Send button reset the alwaysOnTop so other windows could steel the focus.
I might have found what I was looking for here. Remains to be seen if I'll try to use it or if we'll change the requirements :)
See this link to find a working SSCCE on how to redispatch KeyEvents to any text component.