Java Swing: dispose() a JFrame does not clear its controls - java

I have a closeWindow() method which uses dispose() for the current JFrame to close down. When I show the window again, the controls (textboxes, lists, tables etc.) still have their previous values in place that were there when I dispose():d the frame... Why is that? Is there another way to completley close and clear a frame?
This is the code that another JFrame uses to show the other window, am I doing something wrong here?
#Action
public void showAddProductToOrderView() {
if (addProductToOrderView == null) addProductToOrderView = new AddProductToOrderView(this);
addProductToOrderView.setVisible(true);
}

Disposing a window will not clear its child text components. Dispose will release native resources. The javadoc for java.awt.Window also states:
The Window and its subcomponents can be made displayable again by rebuilding the native resources with a subsequent call to pack or show. The states of the recreated Window and its subcomponents will be identical to the states of these objects at the point where the Window was disposed (not accounting for additional modifications between those actions).
As suggested by others, create a new instance each time instead. If that's to expensive I believe your best option is to clear sub components when the view becomes visible, e.g. by overriding setVisible.
EDIT:
Remove the null check to create a new frame each time.
#Action
public void showAddProductToOrderView() {
addProductToOrderView = new AddProductToOrderView(this);
addProductToOrderView.setVisible(true);
}
I don't know about the rest of your code, if there's something else depending on the frame being reused. For example, if you have attached listeners, ensure they are unregistered to not leak them.

The simplest thing to do would be to re-create the whole frame (using its constructor) before using show() to show it again. That will give you a whole new set of components, assuming that the constructor creates and places them.

Related

InvokeLater() - will just once be enough?

I use the recommended code to start my interactive program, which uses Swing. :
public static void main(String[] args) {
javax.swing.SwingUtilities.invokeLater(
new Runnable() {
public void run() {
createAndShowGUI();
} } ) };
It creates a JFrame, call it "Foo", and ends when the user closes that window (by using the OS' Close- Window X icon or another OS way to close the app)
I want to display another window, "Bar", get user input, close that window with my own Swing calls, and then display the "Foo" window.
I could reuse the same JFrame for Foo and Bar, and just clear it out in-between. But I prefer to make each of them more independent in their design. So, an ActionListener in Foo would need to close Foo's frame, and call the code that displays Bar.
Do I need to use InvokeLater() to call the code that displays Bar? To get more design independence, should my main() be starting and synchronizing two threads?
User triggered action listener code is executed in the EDT, so you do not need to wrap it again. That said, it may well be that using CardLayout would be more appropriate than multiple frames.
I could reuse the same JFrame for Foo and Bar, and just clear it out
in-between. But I prefer to make each of them more independent in
their design. So, an ActionListener in Foo would need to close Foo's
frame, and call the code that displays Bar.
Do I need to use InvokeLater() to call the code that displays Bar? To
get more design independence, I am unclear on the operation of the
EDT.
you would use pack() and setVisible(true) wrapped into invokeLater in all cases for
for new Top-Level Container - alyways
for container created but never dispayed - always
for container once visible, then hidden and again visible on the screen - always
doesn't matter if is invoked from Swing Listener (by default on EDT) or not
to my point 3rd. to avoiding any unwanted Graphics lacks in the case that you reused Top-Level Container (is specifics, very short moment, but could be visible, but not, never annoying)
old value is visible, then immediatelly refreshed to current
old JComponent is visible, then immediatelly refreshed with current JComponents
relayout/ pack() , the same issue as a.m.
invokeLater to delay (in most casses with success) this event to the end of EDT
see my view translated to the code demonstration about

JFrame and setDefaultCloseOperation(JFrame.HIDE_ON_CLOSE)

On javadoc, the HIDE_ON_CLOSE default option says that
Automatically hide the frame after invoking any registered WindowListener objects.
Now what it means "HIDE"? the realtive object is destroyed or just hide and continue using resources?
On javadoc, the HIDE_ON_CLOSE default option says that
Automatically hide the frame after invoking any registered WindowListener objects.
Now what it means "HIDE"? the realtive object is destroyed or just hide and continue using resources?
HIDE_ON_CLOSE is the same as JFrame.setVisible(false),
then JFrame in only hiden, invisible, isn't destroyed somehow (the same for JFrame.dispose()), by JFrame.setVisible(true) is again visible on the sceen and without any changes
EDIT
#giozh wrote and if i want to destroy the jframe (without close the
entire application)?
by default there isn't any reason, because by default there no reason to create another JFrame, don't do that, use CardLayout (with JFrame.pack() if is neccessary to change JFrames size on the screen)
and all those Object stays and increasing JVM memory, never will be CG'ed, then there isn't siginficant difference for JVM memory between JFrame.HIDE_ON_CLOSE, JFrame.DISPOSE_ON_CLOSE or JFrame.setVisible(false)
(in the casse that you hate CardLayout) you can to remove all JComponents from JFrames ContentPane, then to add new JComponents, set LayoutManager and last code lines (after all changes to the already visible JFrame is done) would be JFrame.(re)validate();, JFrame.repaint(); and JFrame.pack();
hide it in background without destroying it, keep it in memory
HIDE_ON_CLOSE means that it will just disppear but will be running in the background and consuming resources ,though not visible on the screen.
But using EXIT_ON_CLOSE,instead,makes it disappear as well as kills the application (Use this if you want to really close the application)

Why is componentShown() not called?

I have a CardDetailsPanel class which contains several JLabels and JTextFields. This class in contained in a AddCardsPanel and is initialized as follows:
cardDetailsPanel = new CardDetailsPanel(true);
add(cardDetailsPanel, java.awt.BorderLayout.CENTER);
I also have a JLabel that contains instructions. I want to update this label when the CardDetailsPanel first appears and when focus changes to each JTextField. I have found the addFocusListener() method that will work for the later. However, my compenentShown() method isn't working for the former:
addComponentListener(new java.awt.event.ComponentAdapter() {
public void componentShown(java.awt.event.ComponentEvent evt) {
formComponentShown(evt);
}
});
(Okay, I know this is ugly. It was generated by NetBeans.)
private void formComponentShown(java.awt.event.ComponentEvent evt) {
this.frame = (BaseballFrame) this.getParent().getParent().getParent().getParent().getParent().getParent();
}
(Yah, this is even uglier. I'll deal with the chained getParent() calls later. I want to do other things here as well.)
So why doesn't my listener get called? And how do I write a listener that will perform some actions whenever my CardDetailsPanel appears on the screen?
Use an AncestorListener as described in dialog focus.
When a JDialog (or JFrame for that matter) is made visible, focus is placed on the first focusable component by default. There may be times when you want to change this behaviour. The obvious solution would be to invoke the requestFocusInWindow() method on the component you wish to receive focus. The problem is that this doesn’t work all the time.
...
The problem is .. a component can’t request focus unless it has been added to a “realized” dialog. A realized dialog basically means that the Swing JDialog has been added to a peer component that represents a dialog on the underlying OS. This occurs when you invoke the pack() or setVisible(true) methods on the JDialog.
And that is where the ancestor listener comes in handy. For a component in a modal dialog, it will be fired once the component becomes visible, and is realized & focusable.
Edit:
The above comment applies to components in any Swing container, including JFrame and JPanel.

How to preload Swing components

I know this is sort of a vague question, but I will try to make it as clear as possible. When my Java app launches for the first time, it does some checking to see if files and directories exist and checks for an internet connection.
The app then allows the user to move on to the dashboard, which requires loading and adding many Swing components to the Background Panel. This takes time.
I was wondering how I could make it so that during the loading process at the start, the app loads all of the Swing components Images etc. so that they appear instantly when the user executes the command to do so.
I can load all of the components like this:
JButton = new JButton("blah");
but I'm not sure that's enough to make the components appear instantly, wouldn't adding several image filled Swing components at the same time still lag the UI thread, even if it was already "loaded" as seen above?
Thanks!
on the components use
setVisible(false)
for example
public class myParentPanel extends JPanel{
public myParentPanel{
//add all the child components
//Do what ever takes along time
setVisible(false); //this then makes in invisible but still
//allows all the set up code to run
}
public void showParent(){
setVisible(true);
invalidate();
}
}
and then create a method to make them visible when required. Hence all your setting in the constructors ca be called then when you call your method say:
drawWindow()
it then only has to call setVisible(true) and invalidate the screen to call their painting methods :).
An advancement on this would be to *run your setups i.e your checking and loading the panels methods on a separate threads*so you don't have to wait for a sequential loading. So on your loading you may to use an anonymous class
SwingUtilities.invokeLater(new Runnable(){ public void run(){
//do my display set up
}});

How to use setVisible in JFrames?

In my program I have two JFrame instances. When I click next button I want to show next frame and hide current frame. So I use this.setVisible(false) and new Next().setVisible(true). But in Next window if I click back button I want to set previous frame to be visible again and next frame must be ended (which means it must be exited).
Is there any special method(s) to do this? How can I do it?
Consider using CardLayout instead of hunting for how many JFrames there are. Then..
only one JFrame would be needed
any of Next/Back Actions will be only switching between cards
There are lots of examples in this forum - e.g. as shown here.
That is an odd & quirky GUI. I suggest instead to run a JFrame for the main GUI, and when the user wants to search, pop a JOptionPane (or modal JDialog) to accept the details to search for. This will not have the effect described above, but will follow the 'path of least surprise' for the end user.
If you want to destroy a JFrame releasing all associated resources you shold call dispose() method on it.
You may place your JFrames on a list data structure and keep a reference to current position according to the window you are displaying. In that way it will be easy to move to next and previous. But note that each frame added to the list will use memory and will have its state as you placed it in to the list.
If you are trying to create a wizard like UI, you should look up Sun(oracle)tutorial here.
create the instance of your main window in next() window.. and use same method which you chosed befoe to hide your main window, for example if your main window is named as gui then what we have to do is.
gui obj = new gui();
and if you click on back button now than do these also
this.setVisibility(false);
obj.setVisibility(true);
that's all you need.
good luck.

Categories

Resources