I want to display a JDialog so I use this:
SwingUtilities.invokeLater(new Runnable() {
#Override
public void run() { new DialogBox().setVisible(true); }
});
It works fine to display it but then my JDialog doesn't keep the focus, which it needs to (the user should not be able to work using the main UI while that dialog is open).
Is it safe to get rid of the SwingUtilities.invokeLater()?
Oh and according to this question it is not wise to extend JDialog or JFrame, why? That's how I've always done it.
It works fine to display it but then my JDialog doesn't keep the
focus, which it needs to (the user should not be able to work using
the main UI while that dialog is open).
have to setModal(true) or setModalityTypes(various types) for parent, or all windows from current JVM
Is it safe to get rid of the SwingUtilities.invokeLater()
yes exactly, all Top-Level Container should be created on EDT, wrapped in invokeLater(), including JOptionPane
Related
I run my main window in the main method like this:
SwingUtilities.invokeLater(new Runnable() {
#Override
public void run() {
NoteSystem MainWindow = new NoteSystem();
MainWindow.initUI();
}
});
And then when a button is pressed on this form, I create a window by instantiating a class I made. I'm having trouble detecting when the second form is closed and what the textboxes/other controls contained.
What is the proper way to:
a) Fire an event in NoteSystem when the second window is closed
b) allow NoteSystem to check all the components/controls in the second window
I considered using a JOptionPane, but I'd like to create the window entirely in my own class. The idea of having the main window frozen while waiting for response from the second window works for my application though, so if I could use JOptionPane with my own class, that would be ideal.
Thanks
The best way is to use a modal dialog, a window like a JFrame, but that halts program flow in the calling code until it is no longer visible. This way, the calling code will know exactly when the dialog window has been dealt with, since its code flow will resume once again, and so often the calling code will extract information from the dialog window code at that point. A JOptionPane is one type of these, and so is a modeal JDialog (of which a JOptionPane is a sub-type). Either of these can display as complex a GUI as any that is displayed within a JFrame, so don't sell them short. You'll notice that the second parameter of most JOptionPane methods is of type Object, meaning anything can go in there, but most often you'll pass in either a String for a simple JOptionPane, or a JPanel that can be chock full of components and other nested JPanels, and in this way the JOptionPane can display the complex GUI if need be.
For examples, please see:
Passing values between JFrames
action listener to JDialog for clicked button
trouble obtaining variable info from another JFrame
How do you return a value from a java swing window closes from a button?
I have two seperate JFrames but when i click the X in the topright of one, it will exit out of the other also. I have an "exit" button near the bottom to do setVisible(false), but i still have the tendency to use the x button. How would i make it so that it doesnt cancel out of the entire project?
Also, how would i make it so that the second JFrame locks out of the other JFrame untill the second JFrame is closed, like how a popup message works
Don't give your GUI two JFrames. The GUI ideally should have only one GUI. If a separate window is required, then make it a dialog such as a JDialog, and this won't happen.
Also, how would i make it so that the second JFrame locks out of the other JFrame untill the second JFrame is closed, like how a popup message works
You are perfectly describing the behavior of a modal JDialog or JOptionPane. Just use 'em.
Later we'll chat about using CardLayouts to swap views in a single GUI.
Edit, you state:
Im using Netbeans form editor to create them faster but I only see JFrame and JPanel. Can I edit them in Netbeans? I'd rather not do them through scratch Java
You've touched on another zealous belief of mine, that this is yet another reason not to use a code generator when learning a library as one can get too tied into the code generator, that it prevents one from learning the library. I strongly advise you to put aside your code-generation tool and create by hand, referring to the tutorials and API. Then later when you get more familiar with the library, sure use the tool. By the way, an answer to your direct question here is to gear your GUI's to create JPanels, and then use these JPanels where and how you want them -- in JFrames, or JDialogs, or JOptionPanes, or swapped in CardLayouts, or JTabbedPanes or nested in other JPanels,... etc...
You should be using a modal JDialog, not a second JFrame, because JDialogs provide certain functionality such as not adding another window bar to the taskbar, and automatically setting focus when the parent JFrame receives focus. Modal JDialogs prevent user input to the JFrame while it's open, useful for an "Are you sure you want to exit?" dialog, for example.
As for one JFrame exiting the other, you probably have their default close operation set to EXIT_ON_CLOSE. If you do this:
jframe.setDefaultCloseOperation(JFrame.DO_NOTHING_ON_CLOSE);
jframe.addWindowListener(new WindowAdapter(){
public void windowClosing(WindowEvent we){
handleUserWantsToCloseWindow();
}
});
Then you can control what happens when the user wants to close, such as popping up a "Save Changes?" modal JDialog or "Are you sure you want to quit?" modal JDialog. Note that you have to manually dispose of the JFrame if you use this method.
(In my applicaton with Swing GUI) I want to display GlassPane during some work performed in a loop or method, which is called after clicking JButton.
For example:
(action performed after clicking a button)
if (item.equals(button)) {
glassPane.setVisible(true);
someTimeConsumingMethod();
glassPane.setVisible(false);
}
Running this code results in not showing the glassPane during execution of someTimeConsumingMethod() - GUI just freezes for a moment, before result is displayed. Removing last line in that loop (glassPane.setVisible(false);) results in showing glassPane after the method is done (when GUI unfreezes).
Is there a simple way to show that glassPane before GUI freezes, or I need to use some advanced knowledge here? (threads?)
UPDATE1:
I've updated my code according to davidXYZ answer (with two changes):
(action performed after clicking a button)
if (item.equals(button)) {
glassPane.setVisible(true);
new Thread(new Runnable(){
public void run(){
someTimeConsumingMethod(); // 1st change: running the someTimeConsumingMethod in new Thread
// instead of setting glassPane to visible
}
}).start();
// 2nd change: moved glassPane.setVisible(false); inside the someTimeConsumingMethod(); (placed at the end of it).
}
The point of 1st change is that setting glassPane visible in new thread right before running someTimeConsumingMethod in my GUI thread was revealing the glassPane after someTimeConsumingMethod finished (double-checked this).
Now it works fine, thank you for all answers. I will definitely check all the links you provided to actually understand threads!
UPDATE2:
Some more info: someTimeConsumingMethod(); in my application is prepering new Swing Components accoriding to the XML data (cards builded from JButtons and JLabels with few JPanels where needed, and adding them in correct places).
UPDATE3:
I am trying to make it work using SwingWorker's invokeLater method. Now it looks like that:
(action performed after clicking a button)
if (item.equals(button)) {
glassPane.setVisible(true);
SwingUtilities.invokeLater(new Runnable() {
#Override
public void run() {
someTimeConsumingMethod();
glassPane.setVisible(false);
}
});
}
It works not that good as code from UPDATE1 (but still - it works). Problems are:
glassPane loads without .gif animation (file is setted up in custom glassPane class - it works with UPDATE1 code)
there is small delay at the end of "working" process - first cursor changes to normal (from the WAIT_CURSOR), and after very short moment glassPane disappear.
Cursor is changed by the custom glassPane class on activation/deactivation (no delay using new Thread way).
Is it correct way of using SwingWorker's invokeLater method?
EDIT: My mistake, I confused SwingWorker with SwingUtilities.invokeLater(). I guess the image issue is due to GUI freezing when the someTimeCOnsumingMethod starts.
GUI just freezes for a moment, before result is displayed. Removing last line in that loop (glassPane.setVisible(false);) results in showing glassPane after the method is done (when GUI unfreezes).
this is common issue about Event Dispath Thread, when all events in EDT are flushed to the Swing GUI in one moment, then everything in the method if (item.equals(button)) { could be done on one moment,
but your description talking you have got issue with Concurency in Swing, some of code blocking EDT, this is small delay, for example Thread.sleep(int) can caused this issue, don't do that, or redirect code block to the Backgroung taks
Is there a simple way to show that glassPane before GUI freezes, or I need to use some advanced knowledge here? (threads?)
this question is booking example why SwingWorker is there, or easier way is Runnable#Thread
methods implemented in SwingWorker quite guarante that output will be done on EDT
any output from Runnable#Thread to the Swing GUI should be wrapped in invokeLater()
easiest steps from Jbuttons Action could be
show GlassPane
start background task from SwingWorker (be sure that listening by PropertyChangeListener) or invoke Runnable#Thread
in this moment ActionListener executions is done rest of code is redirected to the Backgroung taks
if task ended, then to hide GlassPane
create simple void by wrapping setVisible into invokeLater() for Runnable#Thread
in the case that you use SwingWorker then you can to hide the GlassPane on proper event from PropertyChangeListener or you can to use any (separate) void for hidding the GlassPane
best code for GlassPane by #camickr, or my question about based on this code
You are blocking the EDT (Event Dispatching Thread, the single thread where all UI events are handled) with your time consuming job.
2 solutions:
Wrap the calls to:someTimeConsumingMethod();glassPane.setVisible(false); in SwingUtilities.invokeLater(), this will allow the frame to repaint itself once more. However this will still freeze your GUI.
Move your someTimeConsumingMethod() into a SwingWorker (this is the recommended option). This will prevent your GUI from ever freezing.
Read the javadoc of SwingWorker to understand better what is going on and how to use it.
You may also learn a lot in this tutorial about Swing and multi-threading
JButton startB = new JButton("Start the big operation!");
startB.addActionListener(new ActionListener() {
public void actionPerformed(java.awt.event.ActionEvent A) {
// manually control the 1.2/1.3 bug work-around
glass.setNeedToRedispatch(false);
glass.setVisible(true);
startTimer();
}
});
glasspane here used here is FixedGlassPane glass;
ref: http://www.java2s.com/Code/Java/Swing-JFC/Showhowaglasspanecanbeusedtoblockmouseandkeyevents.htm
Guillaume is right. When you are on the main thread, each line will finish before the next line. You definitely need another thread.
An easy way to solve your problem is to spin off the display of the glasspane in another thread (normal thread or Swing threads - either will work fine).
if (item.equals(button)) {
new Thread(new Runnable(){
public void run(){
glassPane.setVisible(true);
}
}).start();
someTimeConsumingMethod();
glassPane.setVisible(false);
}
That way, a different thread is blocked by setvisible(true) while someTimeConsumingMethod() runs on the main thread. When it's done, glasspane will disappear. The anonymous thread reaches the end of the run method and stops.
I've been struggling with some problem while creating my app based on Swing. I have a main JFrame which consists of:
JMenu
JPanel containing a JButton and a JLabel
JButton is linked with ActionListener. Clicking JMenu (MenuListener) brings up a JDialog with some form. The problem is, when the JDialog is closed (it doesn't make difference whether I do it with dispose() or rather showVisible(false)) I need to click the JButton two times before it triggers for the first time. From now it normally works with one click.
Every time the JDialog is in front, the problem appears.
PS. The JDialog is set to be modal, with JFrame as parent.
It sounds like a focus issue.
The first click restores focus to the app and the second clicks the button. Typically, I have seen this when the JDialog has the wrong parent and focus can not be returned.
Thank you for your answers.
I have considered posting some code, but it involves 4 classes so will be quite long.
I have also tried things with focus before, but nothing helped. What is interesting: if I display the JDialog by new myDialog.showVisible(true) it behaves like I've described. But if I use construction like this:
SwingUtilities.invokeLater(new Runnable() {
public void run() {
new JDialog.setVisible(true);
}
});
it closes normally and parent frame doesn't need to be clicked before responding, but on the other hand the displayed Dialog needs so. Additonally, what I do not understand, after opening the Dialog cursor is placed in the text field and I can write normally, but to click some button on it I must click once on the Dialog, only second and next clicks behave like I want to.
PS. Closing the dialog like in the second included example changes nothing.
I've created a simple Swing panel that, when loaded, takes up my application's entire window. It contains two JTextAreas and a handful of buttons. I want one of the text areas to have the focus when the panel loads, so that the user can immediately start typing instead of having to click on the text area first. How can I achieve this?
By default focus goes to the first component defined on the window.
If this is not the component you want to have focus then you need to request focus once the window is realized.
The Dialog Focus example shows a couple of ways to do this.
See here the Documentation which contains exactlly what you are searching for (I think):
A component can also be given the
focus programmatically, such as when
its containing frame or dialog-box is
made visible. This code snippet shows
how to give a particular component the
focus every time the window gains the
focus:
//Make textField get the focus whenever frame is activated.
frame.addWindowFocusListener(new WindowAdapter() {
public void windowGainedFocus(WindowEvent e) {
textField.requestFocusInWindow();
}
});
You just need to call requestFocus method of Jcomponent class,
public void requestFocus()
On the Component that you want to focus.
And pleas make sure that you call this method after setVisible is called for its parent component.
For example:-
You have a Jframe in which you added a JTextArea, so after calling you should call in following order:-
jframe.setVisible(true);
jarea.requestFocus();