Thread: Verification Window "Do you really want to close?"

What Swing component is Fenster? Is Fenster a child process to another main application container like a JFrame?

ok. ill try that...well i think in this case it can't be made much shorter than it is. my project consists of 3 short classes (i thought the code i posted would be all which is needed):

public class TestProjekt {
 
	public static void main(String[] args) {
		// TODO Auto-generated method stub
        new Fenster();
	}
 
 
}
 
 
import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
 
public class Fenster extends JFrame {
 
	public Fenster (){
    	setTitle ("Wunderbares Testfenster");
    	setSize (600,400);
    	addWindowListener(new FensterListener());
    	setVisible (true);
    	setDefaultCloseOperation(WindowConstants.DO_NOTHING_ON_CLOSE);
    }
    class FensterListener extends WindowAdapter{
    	public void windowClosing(WindowEvent event){
            new JaNeinFenster("Beenden","Wollen sie wirklich beenden?");
    	}
 
    }
}
 
 
 
import java.awt.*;
import java.awt.event.*;
import javax.swing.*;
 
public class Fenster extends JFrame {
 
	public Fenster (){
    	setTitle ("Wunderbares Testfenster");
    	setSize (600,400);
    	addWindowListener(new FensterListener());
    	setVisible (true);
    	setDefaultCloseOperation(WindowConstants.DO_NOTHING_ON_CLOSE);
    }
    class FensterListener extends WindowAdapter{
    	public void windowClosing(WindowEvent event){
            new JaNeinFenster("Beenden","Wollen sie wirklich beenden?");
    	}
 
    }
}

so...yes...i do extend JFrame. The Code is working and it does what it is supposed to do but i don't really understand why as i said before, because i don't know how the dispose() knows what to dispose and how i can get better and more visible control of what is disposed?
which leads me to the question if there is a possibility to use a buttonclick or another event which is triggert in one window to dispose another window? for me that single line dispose(); doesn't feel good. i would find it better if this line would be more specifically leading to the window which i want to dispose.

i hope that was better understandable.

T_T

Its not about getting the job done the most efficient way. If that was the case i could have used an option pane.

I'm trying to learn something about the way this works, so i extended JFrame. As far as i understood this, we have 3 layers here. The buttons are top, the panel mid and the JFrame the bottom layer. My event is triggered by the button (top-layer) but i want to dispose the bottom layer with everything what it has on it. Just typing dispose() worked but i would like to have a structure like 'button is source of the event'-->'where is the button'(panel)-->'what is the frame that carries the panel'-->'dispose this frame and its components'

I've only been studying Java a few years, but I'm confused by your use of the term "layers" and the concept behind it. For example, describing the buttons (what buttons?) as being in a "top layer", the panel (what panel?) in the "middle layer," and the JFrame in the "bottom layer" is questionable, and probably just plain wrong. It may be your visualization of how "it" works, but I can't find a similar description on the web. Do you have a reference (in English) that discusses Swing and its Event architecture this way?

The JFrame is a container into which other components can be placed. Some of those components placed in the JFrame could also be containers into which other components can be placed. In that way, one might visualize the construction like layers on a cake, but I think a better visualization is boxes inside boxes. Multiple boxes can be placed beside other boxes (at the same level?); some boxes can contain other boxes, and some of the boxes can't. Keeping track of levels isn't useful as far as I can tell. Frankly, the box visualization isn't necessary either.

Components and containers can influence the others to the degree they are aware of one another and to the degree allowed by the other component's interface. Your use of dispose() is a way, but depending on what you're trying to do, I believe there are better approaches available to accomplish the same thing.

Again, an SSCCE would be very helpful to see what you're doing and why you're thinking what you're thinking, to offer comments that may explain it better, and perhaps give you an alternative explanation of what's going on that improves your understanding. It's okay that the programmer-generated items in the code are in a foreign language. Most of us can deal with that. Names are names.

Originally Posted by Wolfone

As far as i understood this, we have 3 layers here. The buttons are top, the panel mid and the JFrame the bottom layer.

Maybe this page explains a little about the "layers"

Originally Posted by Wolfone

My event is triggered by the button (top-layer) but i want to dispose the bottom layer with everything what it has on it. Just typing dispose() worked but i would like to have a structure like 'button is source of the event'-->'where is the button'(panel)-->'what is the frame that carries the panel'-->'dispose this frame and its components'

dispose() is a method defined in java.awt.Window
java.awt.Frame extends Window
javax.swing.JFrame extends Frame
Fenster extends JFrame
JaNeinFenster extends Fenster
So at the end of the day JaNeinFenster "is a" Window
When you call dispose() from within the context of a JaNeinFenster, it means dispose this window

First thing: thanks you two

To greg: -to be honest i thought what i posted was an SSCCE because it is the whole programm code which is functional and short as well -.-
-i can't find the original page which gave me the impression of layers but it had a picture in it very similar to this:
How to Use Root Panes (The Java™ Tutorials > Creating a GUI With JFC/Swing > Using Swing Components)
I'm not very used to the standard vocabulary in this context, so layers was just what it looked like to me from pictures like that and i found that to be logical because in my example i first created the JFrame where add the JPanel and to the JPanel i add my buttons, so it was for me like the cake you described. When boxes is the usually used term i am fine with that, and i am aware of the fact that there can exist different objects beside each other on/in a box. Theres one thing more which makes me think this way: first i tried to add the buttons just to a Frame where one button was completely covering the first added button. Then i read a little bit and added the JPanel to my JFrame which provides some build-in organization functionality if i am right.

To jps: ok that makes things a little bit clearer, i didn't think about the fact that dispose() was a method of the window.
is it right when i say the different steps i wanted to go in my last post can not be done because i already am at the ending point because dispose is a window method and there is nothing other to dispose in this context (because if i wanted to dispose for example a second window i had to reference to it?)?

As for the SSCCE, you may have meant that to be post #4, but I'm assuming you pasted in a second copy of class Fenster rather than class JaNeinFenster that we need to run it.

Yes, I thought of that same layers diagram when I read your original post, but those visual or content layers all belong to the container. When the container goes, all of the layers go, and as jps pointed out, the dispose() method closes the container. Or, more accurately:

dispose(): Releases all of the native screen resources used by this Window, its subcomponents, and all of its owned children. That is, the resources for these Components will be destroyed, any memory they consume will be returned to the OS, and they will be marked as undisplayable.

The reason you saw the behavior you observed when adding things to your JFrame without the JPanel is because the JFrame uses BorderLayout by default and components are added to the BorderLayout.CENTER position if no other position is specified, and only one component can be in each position at a time. The second button you added to the JFrame replaced the first.

The JPanel default layout manager is the FlowLayout so that components added are laid in the container one after the other from top left, across to the right in a top row, continuing by adding more rows as needed and as the container size allows. The Swing LayoutManagers give the programmer great power in creating user interfaces but are also often criticized as being Swing's most difficult and unnecessarily complex concepts to understand.

What you're doing is often done with a JDialog child to a JFrame that serves as the application's main user interface. The JDialog can be modal or non-modal, an option not available with JFrames, so that it can take control of the program and require user input to continue. If the user chooses to 'quit' the program from the JDialog, the action listener tied to that choice can easily do what you've described, closing the entire application.

Originally Posted by Wolfone

(because if i wanted to dispose for example a second window i had to reference to it?)?

If one window attempts to close a different window there can be all sorts of complications. The best way for windowA to close windowB would be for windowA to call a method in windowB and let windowB close itself, and yes you would need a reference to it. They can't allow a program to just go around closing windows

Thanks again to you two !

My vision gets clearer!

to Greg: T_T i really did!! sry i didn't see that!
actually i changed the way it works in the last few days. i let go of the class Fenster because it didn't provide more functionality than the JFrame already does (even if it was just for exercising...). in my first version my JaNeinFenster just exited the running programm. i know there are things like optiondialogs but i wanted to try something like that myself. i changed it so has a boolean in it which just tells me if yes or no was choosen, to make it usable for any situation where a yes/no decision is needed.

in my main window i use it this way

this.addWindowListener(new BeendenListener());
...
class BeendenListener extends WindowAdapter{
	    	public void windowClosing(WindowEvent event){    
	            final JaNeinFenster Auswahl = new JaNeinFenster("Beenden","Wollen sie wirklich beenden?");  // wieso muss das final sein?
	            Auswahl.addWindowListener(new WindowAdapter(){
					public void windowClosed(WindowEvent e) {	
						if (Auswahl.JaoderNein==(true)){
							System.exit(0);
						}
					}
	            });
	    	}
	   ...

where JaoderNein saves the boolean. (i know this is not runnable (again) but the programm is way more complex at this point and i want to minimze the code i post here)
it works fine but there are two things left i'm uncomfortable with.
first: why is it necessary to make Auswahl final, i read several things about he compile error"Cannot refer to a non-final variable i inside an inner class defined in a different method" but i don't understand the necessarity at all.
second: i seem to not really understand the event windowClosed. i read the oracle documentation about this and i don't really understand why it is OK to access a variable of the window (which is supposed to be closed at this time)...in my understanding this should produce an error which says that this variable doesn't exist any longer, but it works just fine...
ok i did some testing on this and it leads me to the conclusion that the object really gets destroyed AFTER everything in the windowClosed method is done; am i right with that?

to jps: very usefull advice! thanks for that; i will try to keep that in mind. i really am a beginner and i have a lot of problems when it comes to the clever use of existing structures. i lack experience with questions like "how is this or that functinality implemented in the best way?" i did a lot of work on refactoring my multiexample-programm which im writing. i try to develop a small programm which will help me in the future as a little lexicon, including intelligent structuring of class hierarchies as well as basic informations about how different data types work and things like that.
seeing things in praxis is another thing than just theoretically know the concepts in my opinion.