In Java's AWT FocusEvent class:
There are two levels of focus events: permanent and temporary.
Permanent focus change events occur when focus is directly moved from one Component to another, such as through a call to requestFocus() or as the user uses the TAB key to traverse Components.
Temporary focus change events occur when focus is temporarily lost for a Component as the indirect result of another operation, such as Window deactivation or a Scrollbar drag. In this case, the original focus state will automatically be restored once that operation is finished, or, for the case of Window deactivation, when the Window is reactivated.
In JavaFX, a ChangeListener can be added to the focusedProperty as shown here, but how does one determine if the change is permanent?
Related
I need to scale my dialogs, when moving them to a different screen. Since scaling all components is quite expensive, I only want to do it once, when the dialog is moved to its new location.
So I used a timer, which restarts with every incoming componentMoved event, to know, when the dialog stops moving. This works great, as long as the mouse is released when stopping the dialog.
If the dialog stops moving and the mouse is still pressed, scaling works. But as soon, as I release the mouse, my L&F engine resizes the dialog to its previous size, which is very inconvenient.
I tried pack(), setting the size manually (I know, bad practice), I tried setVisible(false) before scaling and setVisible(true) afterwards, but as long as the mouse is pressed, my L&F engine resizes the dialog to its previous size.
Sadly, all MouseEvents concerning the titleBar are swallowed by the engine, so I cannot simply use a mouseReleased event to trigger scaling.
This is why I need to find out, if the mouse is still pressed without having to use an event. Is there any way? JNI somehow?
I cannot show an example, because without the L&F Engine, it works fine. Not using it is also not an option.
I think, you should use ComponentListener. When windows size is changed, your layout manager must trigger relayout and component sizes must be changed.
Also for debugging purposes you can use AWTEventListener to get all events which are thrown in your UI.
Toolkit.getDefaultToolkit().addAWTEventListener(...);
setting the size manually (I know, bad practice)
It's not a bad practice. Especially when you want to restore previous size of your window. pack() is simply preferred way.
The list of SWT constants in the SWT API supplies two very similar event types (for use with various event listeners):
Show
Paint
What's the difference? Wouldn't all 'Show' events require a 'Paint' event and all 'Paint' events require a 'Show' event?
According to this page:
Show:
The widget is becoming visible
Paint:
A control was asked to draw
So the main difference is the following:
SWT.Show is dispatched once the Widget becomes visible. SWT.Paint is called whenever the Widget changes state, i.e. when it has to be redrawn. For example when it is resized or the content changes.
To answer your last question. Every Show event is coupled with a Paint, but not every Paint is coupled with a Show.
To see how it works just attach two Listeners to a Shell that just print out "Show" or "Paint" and see when they are fired.
I'm currently having problems with SWT KeyEvents. In an RCP application I have several controls that will be focused if you are tabbing through, e.g. first toolbar icon, another one, finally the editor and a class which is in the editor (a composite, it'll be focused as well).
This particular class receives key events; only - of course - if it is focused and I need to process these events (remember this class gets focus after the editor was focused because the editor holds an instance)
Is there any way to guarantee that this composite will have focus if for example the mouse is over this area?
Already tried to solve this with MouseEvents but even then setFocus() does not always provide focus (same goes for forceFocus()).
I have a simple GUI with a JTextField and an AWT Canvas (to prevent the counter-question as to why I'm using an AWT Canvas: I need to have a window handle).
The Canvas is to process input events, that means it must be focusable. I assure this by using setFocusable(true) in its constructor, later checks using isFocusable() confirm that it is indeed focusable.
Now, the JTextField gains the focus by default when the GUI opens. That's fine by me so far. However, there is no way to get the focus away from that JTextField.
The article "The AWT Focus Subsystem" clearly states that if a focusable component is being clicked on, it will gain the focus. This does not happen, in fact, I receive zero focus change events whatsoever, only if the window gets deactivated and activated again, but then the focus is right back to the JTextField.
Explicit invocations of requestFocus() and requestFocusInWindow() do not help either, the latter always returns false.
I have gotten the same results with any focusable component if I replace the JTextField. If the Canvas is the only focusable container, everything works fine because it will always have the focus.
Am I missing something here? Is there any way I can make my Canvas gain focus in the presence of another focusable component, preferably without making that one unfocusable?
basically in swing focus gained 1st. left(ToRight) JComponents on the top
in most completed GUI, and if there (together with creating JComponents) are added Listeners to the JComponents, then these Listeners (f.e. Document) can take focus...
but works for me on startUp:
last lines in something class about JComponets ..
myFrame.pack();
myFrame.setVisible(true);
Runnable doRun = new Runnable() {
public void run() {
myComponent.grabFocus();
myComponent.requestFocus();//or requestFocusInWindow
}
};
SwingUtilities.invokeLater(doRun);
Sorry for leaving some info out that turned out to be the root of the problem.
As mentioned, I'm using a heavyweight component so I have a window handle. I need one because it is passed to an OpenGL application in a native library, the AWT canvas is then used as a rendering canvas.
In Windows, Java uses the GWLP_USERDATA window field to store a pointer to an AWTComponent object. However, said OpenGL application overrides that field to store its own Window object pointer, which will of course break all AWT related functionality.
I solved this problem by creating a custom window message handler that delegates incoming messages to both the OpenGL application and Java's AWT part.
I have JTextField with FocusListener that call textfield.grabFocus() every time when textfield lose focus. But unfortunetly, it allow parent Window to react on user action. Is there any way to don't give the focus to the Window using only JTextField methods?
If I'm understanding you correctly, you don't want any other controls on your program to be usable while this field requires focus. The problem is, each object is likely to have at least one event listener waiting for some action to occur, and stealing your focus away from you.
You can make all objects not focusable by setting setFocusable(false) for each object, but that will still allow events to be captured.
I'd override/replace (or possibly completely remove, if really necessary) the event listeners on all the other objects to only perform actions when the proper conditions are met (when your object doesn't require focus, if that would ever occur). If overridden/replaced, each listener could then return focus to the JTextField if those conditions are not met.
Also, it is better to use requestFocus() or requestFocusInWindow() instead of grabFocus(). See JComponent grabFocus() and JComponent requestFocus() for more information.