I have a very strange scenario which unfortunately I cannot prevent from occurring in my Swing application. When it occurs however, it has major consequences for me. Perhaps somebody could help!
The basic setup is as follows:
Linux environment.
Multiple JTextFields in a JFrame.
JTextFields push through transferFocus() when the Enter key is pressed.
A JDialog pops up on leaving one of the fields which requires the Enter key to be pressed to remove it.
The situation that causes the issue is as follows:
The Enter key is held down for a few seconds.
When the enter key is held down, the focus obviously flies through the different text fields. When the dialog box is shown, the enter key closes it causing the focus to then continue to fly through the text fields. Eventually, within a couple of seconds, Java breaks. The textboxes immediately stop responding to key strokes - you cannot type anything in them at all. Other than that, everything seems normal - you can click around and focus on different textboxes, close the application etc.
I have created a simple test case you can use to recreate the situation.
The JFrame:
public class TestSwing extends JFrame {
JTextField jtfText1, jtfText2, jtfText3;
TextHandler handler = null;
public TestSwing() {
super("TextField Test Demo");
Container container = getContentPane();
container.setLayout(new FlowLayout());
jtfText1 = new MyJTextField(10);
jtfText2 = new MyJTextField(10);
jtfText3 = new MyJTextField(10);
container.add(jtfText1);
container.add(jtfText2);
container.add(jtfText3);
handler = new TextHandler();
jtfText3.addActionListener(handler);
setSize(325, 100);
setVisible(true);
}
private class TextHandler implements ActionListener {
public void actionPerformed(ActionEvent e) {
JOptionPane.showConfirmDialog(null, "wait!");
}
}
public static void main(String args[]) {
TestSwing test = new TestSwing();
test.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
}
}
The custom JTextField:
public class MyJTextField extends JTextField {
public MyJTextField(int len) {
super(len);
addKeyListener(new KeyAdapter() {
public void keyPressed(KeyEvent evt) {
int key = evt.getKeyCode();
if (key == KeyEvent.VK_ENTER)
transferFocus();
}
});
}
}
To answer any potential questions up front:
The Enter key must be used to transfer the focus.
The spamming of the Enter key comes from the user leaving something on the keyboard (this is in the retail environment so this happens often).
Simply closing and restarting the application is not really an option as there is no mouse plugged into the computer. The application is booted up automatically on start-up making this scenario devastating as the only way to fix the problem is to restart the machine.
The machines aren't very powerful (processing & memory) which somehow causes the issue to happen a lot quicker than when it's recreated on a development machine.
Is this a bug in Java? Can anyone think of a way to prevent this from happening?
The closest I can get to preventing this from happening is to put a sleep(500) call in the JDialog (mine is extended) before it closes but that's not really a great fix...
I have tested this in JDK 1.6, 1.7 and 1.8. While it takes a bit longer in the later versions for the textboxes to become unresponsive, it still happens eventually.
Thanks in advance!
Xandel
Don't use KeyEvents. KeyEvents are generally used in AWT. Swing has newer and better API's to use (in most cases). In this case a JTextField was designed to respond to an ActionEvent when the Enter key is pressed.
You could try to keep track of the last time Enter was pressed and ignore events that seem to be invoked within the repeat rate of the OS. My repeat rate appears to be around 35ms:
import java.awt.event.*;
import javax.swing.*;
public class MyJTextField extends JTextField
{
private static long lastTime = System.currentTimeMillis();
public MyJTextField(int len)
{
super(len);
addActionListener(new ActionListener()
{
public void actionPerformed(ActionEvent evt)
{
long diff = evt.getWhen() - lastTime;
System.out.println(diff);
if (diff > 50)
{
transferFocus();
}
lastTime = evt.getWhen();
}
});
}
}
Related
Is it possible to make a JTextArea in a way that when the user starts to type when the program is launched it's it automatically starts to type in that JTextArea. Normally the the user first has to click on the JTextArea to start to type in it?
Can I make it that the user does not have to click a JTextArea to start typing it?
EDIT: I've tried using:
textField.requestFocusInWindow();
inside my frame class but that doesn't work.
This called to gain focus and is configurable with your code. There are some samples which use Listeners to change JTextArea at the proper time.
Method .requestFocusInWindow(); might fix your problem in the code bellow:
tabbedPane.addChangeListener(e -> {
Component comp = tabbedPane.getSelectedComponent();
if (comp.equals(pnlFoo)) {
txtFoo.requestFocusInWindow();
} else if (comp.equals(pnlBar)) {
txtBar.requestFocusInWindow();
}
});
Similar issue : Java - how do I gain focus on JTextArea when selecting a new JTabbedPane
This could help for your first run :
frame.addWindowFocusListener(new WindowAdapter() {
public void windowGainedFocus(WindowEvent e) {
textArea_1.requestFocusInWindow();
I'm currently trying to build a small program for school. If you click on a checkbox it should show other elements. I learned in python that you need a while loop because the program needs to go over the same lines again where you check if the box is checked but if i put a loop the whole program won't start. I don't understand why.
import javax.swing.*;
import java.awt.*;
import java.awt.event.*;
public class test extends JFrame {
private JCheckBox moredetailscheck;
private JTextField inputfielduser;
public static void main(String[] args) {
test venster = new test();
venster.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
venster.setSize(800, 600);
venster.setVisible(true);
venster.setTitle("true");
venster.setResizable(false);
}
public test() {
setLayout(new FlowLayout());
moredetailscheck = new JCheckBox("checkbox", false);
add(moredetailscheck);
inputfielduser = new JTextField(15);
while(true) { // you want to let the program keep going over these lines
if(moredetailscheck.isSelected()) {
add(inputfielduser);
}
}
}
If you click on a checkbox it should show other elements.
So, you would attach a listener to the JCheckBox, here an ItemListener, that responds when the state of the JCheckBox changes.
I learned in python that you need a while loop because the program needs to go over the same lines again where you check if the box is checked
This is called "polling" and is needed for linear console programs where you need to continually obtain input from the user, again in a "linear" fashion. In these types of programs, you the programmer are in complete control over program code flow, but that's not what you want here.
but if i put a loop the whole program won't start. I don't understand why.
That's because you're now using an event-driven GUI library, there the Swing library, and by calling a while (true) loop on the event thread, you completely block it, rendering your GUI useless. Your program is starting, but it can't construct the GUI, draw itself or listen for events.
Solution:
Get rid of the while (true) loop. Again, it is useful for simple console programs but not in this situation.
Add an ItemListener to your JCheckBox. You can find out how to do that in the check box tutorial
Don't keep adding items to your GUI. Use a CardLayout to swap views. The tutorial can be found here: CardLayout tutorial.
Or even better, have all the GUI items on the GUI at startup, but use the JCheckBox state to enable/disable an item.
As an aside, you will want to learn and use Java naming conventions. Variable names should all begin with a lower letter while class names with an upper case letter. Learning this and following this will allow us to better understand your code, and would allow you to better understand the code of others.
For example:
import java.awt.event.ItemEvent;
import javax.swing.*;
public class TestCheckBox extends JPanel {
private static final long serialVersionUID = 1L;
private JCheckBox moreDetailsCheck = new JCheckBox("More Details", false);
private JTextField inputFieldUser = new JTextField(15);
public TestCheckBox() {
inputFieldUser.setEnabled(false);
add(moreDetailsCheck);
add(inputFieldUser);
// add a listener to the JCheckBox
moreDetailsCheck.addItemListener(e -> {
// if checkbox selected, enable the text field. else disable it
inputFieldUser.setEnabled(e.getStateChange() == ItemEvent.SELECTED);
});
}
private static void createAndShowGui() {
TestCheckBox mainPanel = new TestCheckBox();
JFrame frame = new JFrame("Test CheckBox");
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
frame.getContentPane().add(mainPanel);
frame.pack();
frame.setLocationRelativeTo(null);
frame.setVisible(true);
}
public static void main(String[] args) {
SwingUtilities.invokeLater(() -> createAndShowGui());
}
}
In Java, the AWT starts a thread to handle events automatically; you just let main finish and the program keeps running anyway until you call System.exit. You do need event handlers, though, for which any number of tutorials exist.
(Incidentally, your infinite loop comes before even showing your JFrame.)
I've been making a program that reads from a file, identifies common "posts" in the file, and makes a summary of these. My problem is that the GUI-event that allows the user to specify the name and search-term of the post, does not interrupt the running of the program, like I want it to.
I can make it stop, but then the GUI will not be correctly displayed. I have tried some solutions, which will be specified at the bottom of the post.
EDIT: removed codedump and added something resembeling an SSCCE:
class SSCCE{
public static void main(String[] args) {
SwingUtilities.invokeLater(new Runnable(){
#Override
public void run(){
new Gui();
}
});
}
}
class Gui implements ActionListener{
boolean runn=true;
JFrame wind2;
JTextField nameF, searchtermF;
JButton done;
Gui(){
runEx();
}
public void runEx(){
int i =0;
while(runn){
if(i==10) break;
System.out.println("Open window and record information given! One at the time!!!");
System.out.println(" ");
giveName("test");
i++;
}
}
public void giveName(String s){
JLabel nameL = new JLabel("Give this post a name:");
JLabel searchL = new JLabel("What do you want the searchterm to be?");
wind2 = new JFrame("EazyMoney");
wind2.setLayout(new BorderLayout());
JPanel all = new JPanel();
all.setLayout(new GridLayout(2,2));
searchtermF = new JTextField(30);
nameF=new JTextField(30);
all.add(nameL);
all.add(nameF);
all.add(searchL);
all.add(searchtermF);
done = new JButton("Press when you have filled in the information!");
done.addActionListener(this);
String prn = "The post in question: " + s;
JLabel header = new JLabel(prn);
wind2.add(header, BorderLayout.NORTH);
all.setVisible(true);
wind2.add(all, BorderLayout.CENTER);
wind2.add(done, BorderLayout.SOUTH);
wind2.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
wind2.pack();
wind2.setLocationRelativeTo(null);
wind2.validate();
wind2.setVisible(true);
}
public void actionPerformed(ActionEvent e){
System.out.println("Action recorded, new window can now be shown. All information stored.");
System.out.println(" ");
}
}
The solutions I have tried is:
A simple block, that does a while(true){} and sets the variable to true after the first instance of g.giveName() have been called. I used the ActionListener to call a method that then changed the variable to false again, when the necessary input was given. This resulted in a gray box, with nothing in it.
Making a cyclic barrier that did the same as the block above. Used a separate thread to call g.giveName() and then call the await() from the action listener. Same result as above.
Making readFile be run by a separate thread and call invokeAndWait() on the g.giveName() function. Gave cannot call invokeAndWait() from the EDT-thread, even though it was run from a new thread.
I can not give examples of the code used in instances above, as I have tried a lot of different solutions and do not have it any more. Please take into account that it might have been implemented wrong, and thus might be a valid answer to my question, even though I could not seem to get it to work!
Final note: all work can be found here, if you wish to test the code:
https://github.com/Robiq/EazyMoneyWork
The way to avoid blocking the EDT if you need to execute something else on the same thread it is to temporarily create a new event queue. Here is some example code. In this case it blocks the current thread waiting for some other event to be signalled but you could replace this with whichever long running process is required.
First check if you are running on the EDT: SwingUtilities.isEventDispatchThread. Then if you are:
EventQueue tempEventQueue = new EventQueue();
Toolkit.getDefaultToolkit().getSystemEventQueue().push(tempEventQueue);
try {
wait();
} catch (InterruptedException ex) {
// stop waiting on interrupt
} finally {
tempEventQueue.pop();
}
Something similar to this is how modal dialogs work in Swing. However in general it's not good practice. Much better is to understand which events to listen for to perform specific actions. In your case the user event should not 'stop' your program - it should disable inappropriate components until the user has responded and then re-enable them.
I am making a text based game, but I am having a rather large problem. This problem is that when I assign a new ActionListener to a button that already has an ActionListener assigned to it, it does both of the actions. Here's my code:
while(shouldLoop) {
if(Player.loc == 1) {
left.setText("Do nothing");
left.addActionListener(new ActionListener() {
#Override
public void actionPerformed(ActionEvent e) {
nar1.setText("You are still in a dungeon."); //Here's my first assignment
}
});
right.setText("Pick the lock");
right.addActionListener(new ActionListener() {
#Override
public void actionPerformed(ActionEvent e) {
Player.loc = 2;
}
});
} if(Player.loc == 2) {
nar1.setText("You are now outside");
nar2.setText("the door. What now?");
forward.addActionListener(new ActionListener() {
#Override
public void actionPerformed(ActionEvent e) {
nar1.setText("You hear a guard.");
nar2.setText("What do you do now?");
Player.loc = 3;
}
});
left.addActionListener(new ActionListener() { //Here's another
#Override //assignment to
public void actionPerformed(ActionEvent e) {//the same button
nar1.setText("You hear a guard."); //so when I press
nar2.setText("What do you do now?"); //it here, it
Player.loc = 3; //performs the
} //original assignment
});
right.addActionListener(new ActionListener() {
#Override
public void actionPerformed(ActionEvent e) {
nar1.setText("You hear a guard.");
nar2.setText("What do you do now?");
Player.loc = 3;
}
});
right.setText(rgt);
forward.setText(fwd);
back.setText(bck);
left.setText(lft);
forward.setVisible(true);
} if(Player.loc == 3) {
forward.setVisible(false);
right.setText("Sneak around him!");
left.setText("Fight him!");
}
Thanks for helping,
billofbong
Why don't you just hoist the addActionListener code out of the while loop?
Anonymous inner class listeners look nice in quick and dirty example code, but, in practice, they are a horrible idea. You are learning one of the reasons. Other reasons are that they can't readily be subclassed or modified via Dependency Injection types of things, can't readily be shared (say a button, a toolbar icon, and a menu do the same thing), can't readily be enabled / disabled, (say, "Save As" should be disabled cause nothing is open) etc...
For this use case, break them out into some series of actual Listeners, perhaps organized in a class, array, or some Enums, so they can get swapped in and out.
You are mixing data with code in a bad way by hard-coding the logic of your program in the program itself, and this is the main source of your current and future problems. This won't work, at least not without a lot of kludges.
I suggest you try to separate your data out of your code and make your program more MVC-ish, which stands Model-View-Controller (or one of its many variants). For instance the logic of the program is held by the Model and this includes the non-visualized map of the land being explored, the position of the player in this map, his companions, and your inventory of items that you've collected. So you will likely have several non-GUI classes such as Player, Map, Item (this may be an interface), Room, etc... The Map itself, the possible items, there locations, will be specified in a data file, perhaps a text file for a simple program or a database for a more complex one, and you will need classes to read and parse this file(s).
The View of your program is your GUI, and it should be as dumb as possible. Here is where you'll have your buttons, your text display, and if fancy, a graphical display of your game. No program logic goes in here. None.
The Control will be the Action Listeners that you add to your JButtons and any other code that has to deal with handling user input. But this code could be relatively simple, and it's main task is to pass user interactions to the model. So for instance if the left button is pressed, it may be simply something like
model.leftButtonPress();
Then the model will decide what to do with a left button press, if anything. The model will know where you are in the game for instance, if there's a door to your left or if it's a wall, and based on the state of the model your game will perform the requisite action.
I'm currently trying to receive key events during a drag and drop, but it seems to me that the focus is taken away while dragging so that I can't listen to any key events.
I'm dragging a JComponent subclass that implements KeyListener and requests the focus in the DragSourceListener's dragEnter method, but my assumption is that the focus is taken away from it afterwards.
Now, who's got the focus and how can I take it away back to my JComponent. Or is there a different approach that is more suitable for dnd?
Thank you in advance.
UPDATE:
It's a lot of code necessary to make this work so I'm only going to post some snippets to show you what I'm trying to do:
public class Stone extends JComponent implements Serializable, KeyListener {
public Stone(...) {
//...
setFocusable(true);
addKeyListener(this);
this.dragSource = DragSource.getDefaultDragSource();
this.dgListener = new StoneDGListener();
this.dsListener = new StoneDSListener();
this.dragSource.createDefaultDragGestureRecognizer(
this,
DnDConstants.ACTION_MOVE,
this.dgListener
);
//...
}
//...
public void keyPressed(KeyEvent e) {
System.out.println("Stone: "+e.getKeyCode());
}
//...
public class StoneDSListener implements DragSourceListener, Serializable {
//...
#Override
public void dragEnter(DragSourceDragEvent dsde) {
//...
Stone.this.requestFocus();
addKeyListener(Stone.this);
}
//...
}
}
What happens is that before I'm dragging the Stone component my JPanel has the focus so it receives any keys I'm pressing.
During the drag I can't listen to any pressed keys(so I don't know who's got the focus) even though I'm requesting it when in dragEnter() and after I release the Stone any key events are send to the Stone.
It's probably not important for the question but to illustrate what I'm doing here's a screenshot:
image showing the "drag" http://img685.imageshack.us/img685/1884/pico.png
(Here I'm dragging the Stone from the collection below to the game field on the top). In this state I don't know how to find out what keys are pressed. I need to figure this out in order to be able to rotate the Stone.
Not sure who has focus during a drag and drop. But an alternative solution to your problem would be to add a KeyEventDispatcher for your Stone class to the KeyboardFocusManager. From the JavaDoc:
The KeyboardFocusManager is both a centralized location for client code to query for the focus owner and initiate focus changes, and an event dispatcher for all FocusEvents, WindowEvents related to focus, and KeyEvents+.
+ my emphasis.
Basically we use similar sort of code to intercept KeyEvents before they hit the Component that has focus.
Just gave it a quick test for your particular drag and drop context and it seems to work alright (as long as your application has focus within the operating system). Essentially something along the lines of:
Public Stone(...) {
// ...
KeyboardFocusManager fm = KeyboardFocusManager.getCurrentKeyboardFocusManager();
fm.addKeyEventDispatcher(
new KeyEventDispatcher() {
public boolean dispatchKeyEvent(KeyEvent e) {
System.out.println("Key Press: " + e.getKeyChar());
return false;
}
}
);
// ...
}
You will need to do a bit of leg-work on enabling and disabling when the user is no longer dragging and dropping as my test currently prints all the time.
I also wonder if it is possible to use the KeyboardFocusManager to determine who actually ends up with focus during a drag and drop?
Anyway, I hope this gives you a few new ideas to try.