We Keep Coding

How to know when the gained focus on the first component is initiated by default when parent component became visible or by users actions

I have a popup component which has a first component JTextComponent and I need to recognize in FocusListener where from the focus gained to this component: when popup appears and the component get focus by default or user clicks on it. I didn't find the way to do it using FocusEvent.

Assuming a general use-case, what exactly is it that is tripping you? In my view:
Write the code you wish to execute when focus is gained in a method, say onFocusGained(boolean defaultFocus).
Call it from the FocusEvent methods with onFocusGained(true).
Call it from the MouseAdapter methods with onFocusGained(false).

A method that returns the object last in focus?

so I have a couple JButtons, and hundreds of JTextFields throughout a program (with CardLayout, don't worry). I want these JButtons to find the JTextField that was last in focus, so when the button is clicked, it sets the text of that field to be whatever that button is.
I have tried getFocusOwner() and getMostRecentFocusOwner() on JTextFields that were setFocusable(true)
I'm hoping there's a method already available somewhere for this.

we have getOppositeComponent() in FocusEvent.
which returns the other Component involved in this focus change. For a FOCUS_GAINED event, this is the Component that lost focus. For a FOCUS_LOST event, this is the Component that gained focus. If this focus change occurs with a native application, with a Java application in a different VM or context, or with no other Component, then null is returned.
see documentation for more detail.
or
in the focus lost of TextField assign the textfield to some variable and then use that variable in button click event.

Implications of setVisible() method in Swing

I'm writing a program that uses a few components in a GUI. However, I don't need all of them showing at the same time. In addition, depending on the user's input, there may be times once a component is not in use anymore, that it may or may not be needed again.
So far I have simply just invoked setVisible(false) for each component that I do want to show on the screen. If they are needed again, i simply make them visible.
My question is this. Does setting a component's visibility to false have major implications on performance of a program (generally speaking)? Does the paintComponent method paint a component that is not visible and then just does not show it, or does it ignore it all together?
Also, is it better to just to remove the component from a container instead?

If it is not visible it not being drawn. Lets say I made a button and then made it so it prints "Hello" when I press it. If the button setVisible() is false I won't be able to click on it, its not their.

swing focus issue, lost focus, focusgain not invoked

I have a complex and heavy swing client application which contains many modal compponents, jdialogs, internal frames etc. on some cases, a problem occurs and it is impossible to focus on swing textfields anymore. You may click on some jbuttons, jcheckboxes but it is impossible to focus and edit values on editable jtextfields anymore. The gainfocus events of editable textfields are not triggered anymore, only the requestfocus methods are invoked when you perform click on textfields.
I found a way(hack) so resolve the problematic case, when the trouble case occurs, and you show some joptionpane message or modal jdialog and close it by clicking or disposing, the problem goes away any you may click onto the textfields and edit them.
As a solution, i do some check, if you try focusing on a component, i start a timer thread in the requestfocus event of clicked textfield and keep the instance as focusrequesting component. After some time i check the last focused component by
KeyboardManager.getCurrentKeyboardFocusManager().getPermanentFocusOwner()
If no problem occured, and the textfield gained the focus, the returned object (retur value of getPermanentFocusOwner) is the same instance as the focusrequesting component. But if the problematic case occured, the returned object is different from the focus requesting one and i open my temporarily jdialog by:
JDialog dialog=new OptionPane().createDialog(KeyboardFocusManager.getCurrentFocusManager().getActiveWindow(), "");
dialog.setModal(true);
// MUST be modal to fix the lost focus case
// start closing thread, which closes the dialog after some few time by dialog.dispose
new Closer(dialog).start();
dialog.setVisible(true);
This mechanism works, i now it is not very stable. And on some cases,the dialog.dispose() does not work, the temporarily windows remains always on the screen, not closeable, and because it is modal, client can not do any actions anymore. The dialog MUST be modal to solve the focus problem, because non-modal dialogs does not resolve the focus problem declared above. The dispose method of jdialog has many synchronized blocks, mutex objects etc, I think there occurs some deadlocks.
Any better mechanism suggestions, ideas? I know the best solution is to check the current application, analyse it or rewrite it. But it is very complex, heavy and model and view is not well properly organised. I have short time because the client is waiting, need some temporarily solutions, tricks or hacks.

You may click on some jbuttons, jcheckboxes but it is impossible to
focus and edit values on editable jtextfields anymore.
this is issue (quite common) with JTextField in JWindow without parent (JFrame), use undecorated JDialog instead
I saw here some issue with Focus, FocusSubsystem on Linux OS with last Java version, but never caused to block users input to JTextField
the best workaround for a.m. issue is RequestFocusListener by #camickr
dialog.setVisible(true); should be wrapped in invokeLater(), more see in Initial Thread (valid for all Top-Level Containers created on runtime too)
nothing clear from your question without posting an SSCCE, short, runnable, compilable, demonstraded, caused with a.m. issue

AWT Canvas cannot gain focus in the presence of another focusable component

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.