I have a GUI that extends JFrame which is created by this constructor of another object:
public Engine(int width, int height) {
//ui is the GUI object declared as a field of this object
ui = new UI(width, height);
ui.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
ui.setVisible(true);
}
The GUI's eventListener also creates new threads when certain buttons are clicked:
public void actionPerformed(ActionEvent actionEvent) {
if(actionEvent.getSource().equals(ui.play)) {
if(clickerThread == null) {
autoClicker= new AutoClicker();
clickerThread = new Thread(autoClicker);
clickerThread.start();
}
}
}
Does this mean when I hit the X button on the window, everything related to this program (such as the autoclicker thread, everything in the memory allocated to this program) get cleared and does not slow down the computer in the future?
Or, would System.exit(0) be needed somwhere somehow in order to make it as if this application was never opened after the computer had started and closed the application?
Thanks in advance!
Per the JFrame API:
public void setDefaultCloseOperation(int operation)
Sets the operation that will happen by default when the user initiates a "close" on this frame. You must specify one of the following choices:
DO_NOTHING_ON_CLOSE (defined in WindowConstants): Don't do anything; require the program to handle the operation in the windowClosing method of a registered WindowListener object.
HIDE_ON_CLOSE (defined in WindowConstants): Automatically hide the frame after invoking any registered WindowListener objects.
DISPOSE_ON_CLOSE (defined in WindowConstants): Automatically hide and dispose the frame after invoking any registered WindowListener objects.
EXIT_ON_CLOSE (defined in JFrame): Exit the application using the System exit method. Use this only in applications.
So yes, this will exit the application by calling System exit for you.
Just a little side warning: if your threading is wired incorrectly, and you have long-running code that happens to tie up the Swing event thread, the EDT, then the JFrame's termination button won't respond until the EDT is unblocked.
Side recommendation 2, regarding:
I have a GUI that extends JFrame...
I recommend against creating classes that extend top-level windows such as JFrames since this creates inflexible classes that can only be used as a JFrame. Much better to gear your GUI classes to create (or if need be, extend) JPanel since this way your GUI can be displayed in many different contexts -- in a JFrame, a JDialog, in another JPanel, in a JTabbedPanel... it frees your code up a bit.
Side recommendation 3: regarding creating new threads in a Swing application, if the auto clicker will interact with the Swing application itself, then you may wish to consider using a SwingWorker to help create your background thread since this construct has mechanisms within it that help safe communication between background thread and the GUI without breaking Swing threading rules. Google "Concurrency in Swing" for more on this.
Related
In my program it opens a window if an action is happened. After I have filled out information in this window, and entered a button, the window dispose().
The window is picked up in a program outside my main program, but when I close this window, my main program stops. How can I prevent this from happening?
Thanks for your help!
You can set the defalaultCloseOperation property of the second frame to DO_NOTHING_ON_CLOSE or DISPOSE_ON_CLOSE
Don't even use two frames. Use a modal JDialog instead for a secondary frame. See more at How to Use Dialogs. Read more about Modality. And for a good read, see The Use of Multiple JFrames, Good/Bad Practice?
Forget about number 1. and go straight to 2.
If using JFrame or extending it you can use setDefaultCloseOperation() method like:
frame.setDefaultCloseOperation(HIDE_ON_CLOSE);
// or
frame.setDefaultCloseOperation(DISPOSE_ON_CLOSE);
The dispose command is from the AWT Bundle, and this may cause problems, as you are attempting to "close" a swing window with an AWT command.
You can close the window with this command:
windowName.setVisable(false);
windowName is the name of the object representing the window. If you are extending a class, and have no object, you can use this
More Information on the Dispose Method:
"In general java.awt.Window.dispose() is used on a GUI component that is
a subclass of Window, in order for that specific GUI Window object (and
its children) to properly release and destroy native UI resources (such
as the screen). Garbage collection (and the eventual exiting of the
entire VM) may happen as a result of dispose(), but is not directly
connected with the dispose() call itself." From: https://www.java.net/node/684412
windowName.setVisable(false);
doesn't seems to be a good choice. What if user want to exit the program?
check this question - How to hide a JFrame in system tray of taskbar
i need to develop java code to have JFrame with a text filed and button.Using Threads,i need to update time for every one minute in the title bar of JFrame.Using Another Thread i need to display textbox value in the console when a button is clicked.I have code for performing both operations (updating time for every min and getting text box value)but i dont know how to add two threads in same class.if anyone knows pls help me out
What you are asking is a dangerous thing to do in Swing. Swing components are not thread-safe and should only be updated from the Event Dispatching Thread (also known as the EDT or Swing Thread). To do this, Swing has utility methods such as SwingUtilities.invokeLater(Runnable) which will execute the code in the Runnable (at some point in the future) on the EDT. The idea is that you place your code to do Swing-things (like update the Title of the JFrame with the time) inside of a separate Runnable and pass it to invokeLater().
To do this, you can create an anonymous Runnable class:
Runnable updateJFrame = new Runnable () {
public void run () {
myJFrame.setTitle("My New Title");
}
};
SwingUtilities.invokeLater(updateJFrame);
Using invokeLater() also ensures that the components get refreshed/repainted properly after they have been updated. (The behavior you are seeing when using statics may actually be a refresh/repaint issue.) The moral of this story is that if you manipulate Swing components on a non-EDT thread, all bets are off.
When we implement Listener, Renderer or Editor, inside methods how Java its calling automatically?
Code:
Class A implements ActionListener{
A(){
//bla bla
//bla bla
this.addActionListener(btn);
}
public void actionPerformed(ActionEvent e){**// How actionPerformed method called //automatically if we register button**
}
}
How its calling actionPerformed method automatically after registering button object? We are just passing the btn object into addActionListener(btn). How inside its calling that method?
I checked through netbeans inside addActionListener method*. There is no calling method of actionPerformed method. Also if we register it keeps on working. Is it calling by thread anywhere inside? But i checked source code. nothing is there. How?
Events are dispatched from an EventListenerList, owned by the parent JComponent, using a convention outlined in the API and discussed here. Editors and Renderers are evoked by the owning view component.
Addendum: Can we create interface same as it is? How?
Yes, JFreeChart is a fairly accessible example. Although a chart is not itself a JComponent, it uses the same model for its own events.
In Java, anything which happens upon any windows component is dealt with by the Event Dispatcher Thread:
The event dispatching thread (EDT) is a background thread used in Java
to process events from the Abstract Window Toolkit (AWT) graphical
user interface event queue. These events are primarily update events
that cause user interface components to redraw themselves, or input
events from input devices such as the mouse or keyboard.
Whenever you click or do some event, it is the EDT which kick starts the action listener, which is why doing any Thread.sleep in your action listener will eventually freeze the UI for a period of time.
Since your class implements a given interface, your class will guarantee the EDT that it will have a series of methods which the EDT can use to do whatever it needs.
For more information on the EDT, please take a look at this Oracle document.
It's magic.
Event handling is taken care of for you by the AWT API. These events are then queue and dispatched to the various components (via a serious of steps). Each interested party then handles those requests that are of interest to them before passing them up the food chain till it reaches you.
The question is, should you care?
In some respects yes, but do you care how electricity works or just that you can turn on the light switch?
I'm sure there's better documentation, but you could take a look at http://docs.oracle.com/javase/1.3/docs/guide/awt/designspec/events.html for starters...
Swing calls your ActionListener automatically when the action occurs. The actual method call is located deep inside the source code of Swing.
I'm writing a 2D polygon and physics editor, one functionality is to set a rotation limit for joints.
To use this functionality, the user clicks and drags a line between the joint points which need to receive the limit.
The logic of determining if the pick is valid happens outside of the GUI code.
If a pick is found, I wanted to pop up a JOptionPane.showInputDialog where the user can input the limit.
Thing is, if I do it directly, the program becomes unresponsive, I figure it's because of threading.
I's there a way to define an event listener the GUI can use that doesn't require an actual GUI component?
I want to send an event that also contains a reference to the target object to that component, then telling it that a valid pick has been made and user input is required, and then send the value back via a method of the target object.
I am very inexperienced with Swing.
My hunch is that I might be able to add an ActionListener to the main window, but I don't know how I could address that listener specifically.
As in, how would I need to define an Action that only gets processed by that particular listener?
If that is actually possible, of course.
So far I have only used listeners to let the GUI talk to the logic, not the other way around...
Edit:
The program becomes unresponsive the movement I call
result = JOptionPane.showInputDialog(this,"Enter Limit.");
That just breaks it. Can't even enter anything into the textbox, nor close it, etc.
I figure it's because it spawns a modal dialog that pauses some thread, and calling it from somewhere in the bowels of non GUI code is just not the thing I should do, but I'm too inexperienced to know another way...
Edit2:
I should add that I can use JOptionPane.showInputDialog without any problems if I spawn it, for example, after clicking a button or choosing a popup menu option.
In fact that's how I rename the items I am working with.
But I assume at that point, the dialog is being spawned inside the GUI thread, or this Event Dispatcher queue thing.
The problem with this though is, that this takes visible, interactive GUI components that fire that event.
What I'd like, however, is some sort of component that would spawn JOptionPane.showInputDialog just like a clicked button or context menu would, but without having to be interacted with by the user, but instead by the code.
I guess I could use invisible buttons and emulate mouseclick events, but that's pretty hacky...
Also, I tried spawning Threads and Runnables which spawned the JOptionPane.showInputDialog, but that didn't help either.
Unless I spawn the JOptionPane from a GUI source, everything stalls, and the dialog won't work.
The publisher will have a public add/remove listener, where the subscriber will add itself or be added via another channel to the EventListenerList in the publisher.
You can create your own listener interface that extends EventListener and a function to shoot an event. Below is an example:
import java.util.EventListener;
public interface MyEventListener extends EventListener {
public void myEventOccurred(MyEvent event);
}
You can then create your custom event class, "MyEvent" in the example above like:
import java.util.EventObject;
public class MyEvent extends EventObject {
// customer fields and methods here
public MyEvent(Object source) //more possible args here {
super(source);
//other things here to do what you want
}
}
Now you can have your subscriber implement MyEventListener and override the myEventOccurred(..) method.
Another approach would be to use the SwingWorker class to execute the logic of determining the pick in a dedicated thread without blocking the GUI dispatch thread, and use its callback method to execute the GUI action (open the input dialog).
See : http://docs.oracle.com/javase/6/docs/api/javax/swing/SwingWorker.html
(This page has a better explanation of concept than I could write.)
It should be possible for your background thread to spawn a dialog with invokeAndWait():
final double[] result = new double[1];
SwingUtilities.invokeAndWait(new Runnable() {
public void run() {
try {
result[0] = Double.parseDouble(
JOptionPane.showInputDialog("Enter value:"));
} catch(NumberFormatException e) {
result[0] = -1;
}
}
}
// ... do something with result[0]
Here I made the result an array just so that it can be final (accessible to the anonymous class) and also mutable.
Does it make sense to use setVisible(false) on a dialog and reuse it later or is safer to call dispose() every time and to make a new JDialog.
What about memory leaks with setVisible(false)?
EDIT:
My Question isn't so much about quitting the application. More about Dialogs that have the main frame as parent and are opened and closed during the application life time. E.g. let's say my applications has about 10 dialogs that display different data every time I open them. Should I reuse the instances and use setVisible() or should I make a new Dialog every time and dispose() them on closing.
I would recommend using dispose() to release resources and free up memory. If you want to show the dialog again, simply invoke setVisible(true).
It's important to note that when the last displayable window within the Java virtual machine (VM) is disposed of, the VM may terminate. See AWT Threading Issues for more information.
I still can't see any diference between JDialog#dispose(); and JDialog.setVisible(false) more here, each of them could be wakeup for reuse, and doesn't matter if was/were Disposed or Visibled
my view is that this question must be splited to three separates areas
1) some JFrame is parent for JDialog or JWindow (exist only is is there JFrame), then last one must to turn-off the lights
2) without parent for JDialog
3) there still exist another JFrame, JDialog or JWindow, then last one must to turn-off the lights
reachable by using --> Window[] wins = Window.getWindows();
last one must to turn-off the lights --> System.exit(0);
I suggest that there in all of possible cases must exist visible JFrame with JFrame.EXIT_ON_CLOSE, or another way could be implements WindowsListener with System.exit(0);
Calling dispose() frees the resources associated with the dialog. You can keep the dialog around after you dispose() it. If you are worried about having too many dialogs laying around, use a WeakReference to hold the reference. That will ensure that your dialogs you are not using only survive garbage collection as long as the space they occupy is not needed.
I experienced a difference when a window shall be hiden twice (in cause of bad software design e.g.)
If you dispose an already disposed window the VM hangs. (java 8)
If you setvisible false on an already invisible window life goes on...