Focusable JTextArea not gaining focus.
I am creating a JTextArea and want to give it the focus when it's created. THis happens twice in the program, and the first time it works, the second time the JTextArea is created but doesn't get the focus until I click on it.
In both cases the code is called from the Swing event queue (see the output below). In both cases the class which creates the jTextArea is the same (an extension of JPanel), and is added to a new tab in a tabbed pane.
Because I know that you need to make sure that the component's been created before it gets focus, the code to create it and give it focus is:
private javax.swing.JTextArea jtaInfo;
.
.
.
// Class constructor for outer class
public PanelInfo(String s,boolean editable ){
initComponents();// this is the NetBeans call which creates jtaInfo and a few buttons
jtaInfo.setText(s);
jtaInfo.setEditable(editable);
setVisible(true);
selectTextBox();
}
publicvoid selectTextBox(){
UtilFunctions.tcaProgramInfoMessage("selectTextBox thread="+Thread.currentThread().getName());
SwingUtilities.invokeLater(new Runnable(){
publicvoid run(){
UtilFunctions.tcaProgramInfoMessage("Runnable thread="+Thread.currentThread().getName());
UtilFunctions.tcaProgramInfoMessage("Info frame focusable: "+jtaInfo.isFocusable());
if (!jtaInfo.requestFocusInWindow()){
UtilFunctions.tcaProgramInfoMessage("Failed to give info pane focus");
}
}
});
}
The UtilFunctions.tcaProgramInfoMessage
call produces output with a timestamp.
The output is:
Sat Nov 11 11:25:38 GMT 2006: selectTextBox thread=AWT-EventQueue-0
Sat Nov 11 11:25:38 GMT 2006: Runnable thread=AWT-EventQueue-0
Sat Nov 11 11:25:38 GMT 2006: Info frame focusable: true
Sat Nov 11 11:25:44 GMT 2006: selectTextBox thread=AWT-EventQueue-0
Sat Nov 11 11:25:44 GMT 2006: Runnable thread=AWT-EventQueue-0
Sat Nov 11 11:25:44 GMT 2006: Info frame focusable: true
Sat Nov 11 11:25:44 GMT 2006: Failed to give info pane focus
So it seems that the threads are OK, and the area is focusable, but I can't work out why one succeeds and the other fails. The program's too huge to post here - I may be able to cut it down to size. But is there anything obvious that I might be doing wrong?
[3156 byte] By [
ptoyea] at [2007-10-3 9:35:57]
> Because I know that you need to make sure that the component's been created before it gets focus,
Actually the parent frame or dialog must be "realized" (maybe thats what you mean by "created") before a component can receive focus. This basically means that you've done a pack() or setVisible(true) on the frame. Using setVisible(true) on the actual component does nothing since by default all JComponents are visible.
> The program's too huge to post here - I may be able to cut it down to size
I fail to see why its so difficult to create a short demo program showing the problem. The code you posted doesn't help because we don't know the context of how the code is executed.
Below is a simple demo that shows an incorrect version and a correct version in 10 lines of code. So if this code doesn't help solve the problem you will now need to wait hours again until you post a version of your code that does demonstrate the problem. Whereas if you had spent 5-10 minutes to create a demo that doesn't work I may have been able to help you out right now.
Simplify your problems and the answer will also be simpler.
import java.awt.*;
import javax.swing.*;
public class FocusTest
{
public static void main(String[] args)
{
JTextField textField1 = new JTextField("One");
JTextField textField2 = new JTextField("Two");
JTextField textField3 = new JTextField("Three");
JFrame frame = new JFrame();
frame.setDefaultCloseOperation( JFrame.EXIT_ON_CLOSE );
frame.getContentPane().add(textField1, BorderLayout.NORTH);
frame.getContentPane().add(textField2, BorderLayout.CENTER);
frame.getContentPane().add(textField3, BorderLayout.SOUTH);
// This doesn't work
textField3.requestFocusInWindow();
frame.pack();
// This does work
//textField3.requestFocusInWindow();
frame.setLocationRelativeTo(null);
frame.setVisible(true);
}
}
Thanks - sorry I got the jargon wrong. It was the pack() that was missing - I'd not realised that I had to include it in order to ensure that the new components were corrently realised. setVisible(true) on the frame doesn't work, though.
It would have taken me a LOT more than 10 minutes to knock up a "simple" program that exactly mirrored the combined effects of my code and Netbeans' own code. And you hit the nail right on the head first time - thanks again.
> It would have taken me a LOT more than 10 minutes to knock up a "simple" program that exactly mirrored the combined effects of my code and Netbeans' own code.
I fail to see why. Presumably you click on a button and show a dialog or something. How complex can that be to replicate? And if you are doing something more complex than that, then how are we supposed to guess what you are doing. Why should we waste time guessing what your are doing. Its your responsibility to isolate the problem so we spent as little a time as possible on your question. you are not the only person needing help.
I get extremely frustrated when you think your time is more valuable than ours.
Anyway thats not what I was suggesting. I said simplify the problem. So prove that the simple case works first. Once you prove the simple case works you move on to a more complex case. Then when the code stops working you have something to post on the forum so we don't have to guess exactly what you are doing. This is part of problem solving.
Based on your answer here, because you where not using pack() you would have noticed the problem on your first simple test.
> setVisible(true) on the frame doesn't work, though.
Hmm, it seems to be a bit inconsistent. I removed the pack() statement..
The following works:
frame.setLocationRelativeTo(null);
frame.setVisible(true);
textField3.requestFocusInWindow();
but the following doesn't:
frame.setSize(200, 300);
frame.setLocationRelativeTo(null);
frame.setVisible(true);
textField3.requestFocusInWindow();
I would take me more than 10 minutes because you are a LOT more experienced in programming Swing than I am - you've already proved that! I use NetBeans and Matisse to generate the GUI, and separating out what they do from what I'm doing, and trying to work out which bits I should be coding and which are done automatically isn't exactly obvious. Had I provided the entire set of classes with all of the NetBeans overhead you would, I suspect, have complained with considerable justification that it wasn't simple enough.
I don't want to start a flame war, but I don't regard your time as less important than mine - you're putting words into my mouth. You didn't need to provide the test program (and it seems that you've found something interesting yourself here) - just the words "Try pack() or setVisible(true) on the frame" would have done. I appreciate the extra effort, and have already thanked you for it, but I did ask whether I was doing anything silly. And I was.
I just showed you how to write a 10 line program without relying on Netbeans or Matisse. I did not ask you to write a program in Netbeans or Matisse. I asked you to show the concept of what you where trying to do.
If you don't know how to do that then you shouldn't be using an IDE. You need to learn the basics so you understand how Swing works. Don't rely on an IDE to do the bascis for you until you understand them yourself.
> If you don't know how to do that then you shouldn't
> be using an IDE. You need to learn the basics so you
> understand how Swing works. Don't rely on an IDE to
> do the bascis for you until you understand them
> yourself.
At the risk of going violently off-topic, I think that's a contentious point of view. I choose to use an IDE (and specifically a GUI editor) to remove the humdrum task of programming every aspect of the GUI. That's what computers are for.
If you have to learn the basics before using the system, could I ask if you've ever programmed in binary, punching the holes in the paper tape (or cards) with a dibber? (FYI, I have in the early 1970s on rare occasions and never want to again). Or even assembler? And do you know the principles of tailoring your own (no doubt hair) shirts? :-)
"The computer was made for man, not man for the computer" (Prof. Strachey, early 1970s).
If you want to continue this conversation, I suggest that we open a new thread with a more pertinant subject.
And my point, possibly not well enough made, was that it would take far more than 10 minutes to work out exactly which actions the GUI editor was putting in for me, so that I could reproduce them. No point in the simplfied case not doing the same as the original, after all!
> At the risk of going violently off-topic, I think
> that's a contentious point of view. I choose to use
> an IDE (and specifically a GUI editor) to remove the
> humdrum task of programming every aspect of the GUI.
> That's what computers are for.
>
> If you have to learn the basics before using the
> system, could I ask if you've ever programmed in
> binary, punching the holes in the paper tape (or
> cards) with a dibber? (FYI, I have in the early 1970s
> on rare occasions and never want to again). Or even
> assembler? And do you know the principles of
> tailoring your own (no doubt hair) shirts? :-)
Your analogy to assembler is not appropriate.
You need to understand what you are doing. An IDE is not a higher level of doing it, it is a tool to help you do it faster and better. For example if you where building a house, a bobcat might be very helpful but you still need to know where to move the dirt, etc.
> No point in the simplfied case not doing the same as the original, after all!
Of course there is. 90% of the time the problem is something incredibly simple. Its easier to find this problem in 10 lines of code than it is in 100's of lines of code.
You learn to debug by simplifying the problem. So you start by creating a GUI with two text fields and try to set focus on the second text field to prove that the basic concept works. If you can't get a 10 line program to do what you want then it obviously won't work in a larger program. So you need to understand the basics first before you try something more complex.
In your case here it would not work as I proved in my simple 10 line example.
You are supposed to do some background work before posting a question on the forum. That is you should be isolating where the problem is occuring before you ask a question. That way you give us more information to work with.
Once that works you make is more complicated by mimicking what your application is trying to do. If you don't understand the code that is being generated by your IDE then you shouldn't be using the IDE. How can you debug code you don't understand?
> I choose to use an IDE (and specifically a GUI editor) to remove the humdrum task of programming every aspect of the GUI.
Thats fine, but you still need to know how to create a simple stand alone program to demonstrate a problem. Thats how all the tutorial code works in the Swing tutorial. So you should be able to copy a simple class file into you IDE and compile and execute it.
I've given you the basic structure of a simple stand alone class. You can decide to use it in the future or not. I don't answer questions when the OP doesn't make any effort to provide the necessary information required to solve the problem.
