|
|
 |
 |
 |
 |
Query:the real function of System.exit(0)?
Hello Everybody:
As we all know,System.exit(0) is often used to quit the program.
But when it applied to some of my programs,the outcome was not so.
I created a frame using class JFrame.Then I registerd WindowsAdapter on
the close action,and here came the problem:
When I only used System.exit(0) in the rewrote of method
windowClosing,it cloud never close the window normally.(I could only use
ctrl+c or more often directly kill the process to end this)
But when I added frame.dispose() before it,then it worked well,
here frame is an instance created by JFrame.If the sentence
frame.dispose() came after System.exit(0),neither would it do the job.
Why?
My os is WindowsXP,and jdk version is(created by command java -version):
java version "1.5.0_04"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05)
Java HotSpot(TM) Client VM (build 1.5.0_04-b05, mixed mode, sharing)
Any help will be greatly appreciated!
Dowson.
On Sat, 12 May 2007 17:13:12 +0100, Jack Dowson <jckd @aol.com> wrote: > Hello Everybody: > As we all know,System.exit(0) is often used to quit the program. > But when it applied to some of my programs,the outcome was not so. > I created a frame using class JFrame.Then I registerd WindowsAdapter on > the close action,and here came the problem: > When I only used System.exit(0) in the rewrote of method > windowClosing,it cloud never close the window normally.(I could only use > ctrl+c or more often directly kill the process to end this) > But when I added frame.dispose() before it,then it worked well, > here frame is an instance created by JFrame.If the sentence > frame.dispose() came after System.exit(0),neither would it do the job.
myFrame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
Dan.
--
Daniel Dyer
https://watchmaker.dev.java.net - Evolutionary Algorithm Framework for Java
Jack Dowson wrote: > Hello Everybody: > As we all know,System.exit(0) is often used to quit the program. > But when it applied to some of my programs,the outcome was not so. > I created a frame using class JFrame.Then I registerd WindowsAdapter on > the close action,and here came the problem: > When I only used System.exit(0) in the rewrote of method > windowClosing,it cloud never close the window normally.(I could only use > ctrl+c or more often directly kill the process to end this) > But when I added frame.dispose() before it,then it worked well, > here frame is an instance created by JFrame.If the sentence > frame.dispose() came after System.exit(0),neither would it do the job. > Why?
> My os is WindowsXP,and jdk version is(created by command java -version):
> java version "1.5.0_04"
> Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_04-b05)
> Java HotSpot(TM) Client VM (build 1.5.0_04-b05, mixed mode, sharing)
> Any help will be greatly appreciated!
> Dowson.
Java API) "[this] method never terminates normally."
windowClosing is called before the window is closed, so when you exited
from windowClosing, the VM couldn't close the window.
If you want to exit when the window is closed, use JFrame's
setDefaultCloseOperation.
Jack Dowson wrote:
..
>As we all know,System.exit(0) is often used to quit the program.
>But when it applied to some of my programs,the outcome was not so.
>I created a frame using class JFrame.Then I registerd WindowsAdapter
That is most probably the problem. If you spelt the
method name incorrectly, or using wrong arguments
using a WindowAdapter gives no complaint at compile
time, and no effect at runtime. Try implementing a
WindowListener instead - that forces you to implement
the correct methods.
See if this example works for you..
<sscce>
import java.awt.event.*;
//import java.awt.Frame;
import javax.swing.JFrame;
class CloseWindow {
public static void main(String[] args) {
//Frame f = new Frame("Close Me!");
JFrame f = new JFrame("Close Me!");
f.addWindowListener( new WindowListener(){
public void windowDeactivated(WindowEvent we) {}
public void windowActivated(WindowEvent we) {}
public void windowDeiconified(WindowEvent we) {}
public void windowIconified(WindowEvent we) {}
public void windowOpened(WindowEvent we) {}
public void windowClosed(WindowEvent we) {}
public void windowClosing(WindowEvent we) {
System.out.println(we);
System.exit(0);
}
} );
f.setSize(200,100);
f.setLocation(50,50);
f.setVisible(true);
}
}
</sscce>
Note that for Swing based JFrames, I would heed
Daniel's advice to use defaultCloseOperation(),
but adding a WindowListener works, and does
so for both Swing and AWT based components.
In fact, uncomment the two commented lines,
and comment the two lines following them, and
you might see the same effect on an AWT Frame.
HTH
--
Andrew Thompson
http://www.athompson.info/andrew/
Message posted via JavaKB.com
http://www.javakb.com/Uwe/Forums.aspx/java-general/200705/1
On Sat, 12 May 2007 17:54:59 +0100, Andrew Thompson <u32984@uwe> wrote: > Jack Dowson wrote: > .. >> As we all know,System.exit(0) is often used to quit the program. >> But when it applied to some of my programs,the outcome was not so. >> I created a frame using class JFrame.Then I registerd WindowsAdapter > That is most probably the problem. If you spelt the
> method name incorrectly, or using wrong arguments
> using a WindowAdapter gives no complaint at compile
> time, and no effect at runtime. Try implementing a
> WindowListener instead - that forces you to implement
> the correct methods.
supposed to help you catch these situations by telling the compiler that
you intended to over-ride a method. Of course, you still have to remember
to add the annotation...
Dan.
--
Daniel Dyer
https://watchmaker.dev.java.net - Evolutionary Algorithm Framework for Java
Daniel Dyer ??:
> It's better to do it this way: > myFrame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
> Dan.
I've tried,but it did not work either.
"Daniel Dyer" <"You don't need it"> writes:
>It's worth mentioning the @Override annotation in this context.
This can be used when extending classes,
but not when implementing interfaces.
On Sat, 12 May 2007 18:31:46 +0100, Stefan Ram <r@zedat.fu-berlin.de>
wrote:
> "Daniel Dyer" <"You don't need it"> writes: >> It's worth mentioning the @Override annotation in this context. > This can be used when extending classes,
> but not when implementing interfaces.
WindowListener directly.
Dan.
--
Daniel Dyer
https://watchmaker.dev.java.net - Evolutionary Algorithm Framework for Java
On Sat, 12 May 2007 18:26:53 +0100, Jack Dowson <jckd @aol.com> wrote: > Daniel Dyer ??: >> It's better to do it this way: >> myFrame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); >> Dan. > Thank you very much!
> I've tried,but it did not work either.
need to see the code at this point?
Dan.
--
Daniel Dyer
https://watchmaker.dev.java.net - Evolutionary Algorithm Framework for Java
Thank you so much for helping me again,Andrew.
> That is most probably the problem. If you spelt the
> method name incorrectly, or using wrong arguments
> using a WindowAdapter gives no complaint at compile
> time, and no effect at runtime. Try implementing a
> WindowListener instead - that forces you to implement
> the correct methods.
I've checked every word I spelled,and found nothing wrong.
> See if this example works for you.. > <sscce> > import java.awt.event.*; > //import java.awt.Frame; > import javax.swing.JFrame; > class CloseWindow {
> public static void main(String[] args) {
> //Frame f = new Frame("Close Me!");
> JFrame f = new JFrame("Close Me!");
> f.addWindowListener( new WindowListener(){
> public void windowDeactivated(WindowEvent we) {}
> public void windowActivated(WindowEvent we) {}
> public void windowDeiconified(WindowEvent we) {}
> public void windowIconified(WindowEvent we) {}
> public void windowOpened(WindowEvent we) {}
> public void windowClosed(WindowEvent we) {}
> public void windowClosing(WindowEvent we) {
> System.out.println(we);
> System.exit(0);
> }
> } );
> f.setSize(200,100);
> f.setLocation(50,50);
> f.setVisible(true);
> }
> }
> </sscce>
java.awt.event.WindowEvent[WINDOW_CLOSING,opposite=null,oldState=0,newState =0]
on frame0
and then went back to the former condition.
It was the same result when I uncommented the two commented lines and
commented the two lines following them.
Why?
Dowson.
Daniel Dyer ??:
> That's odd. Do you still have a WindowListener doing something? > Probably need to see the code at this point? > Dan.
That's my simple code:
import javax.swing.*;
public class CloseWindow{
public static void main(String[] args){
JFrame frame = new JFrame("Close");
frame.setSize(300,300);
frame.setLocation(100,100);
frame.setVisible(true);
frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
}
}
On Sat, 12 May 2007 18:45:45 +0100, Jack Dowson <jckd @aol.com> wrote: > Daniel Dyer ??: >> That's odd. Do you still have a WindowListener doing something?
>> Probably need to see the code at this point?
>> Dan.
> Thank you,Dan.
> That's my simple code:
> import javax.swing.*;
> public class CloseWindow{
> public static void main(String[] args){
> JFrame frame = new JFrame("Close");
> frame.setSize(300,300);
> frame.setLocation(100,100);
> frame.setVisible(true);
> frame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
> }
> }
I can only guess that there is a bug in that specific version of the JRE
that you are using, or something odd with your machine. It might be worth
trying a later build.
Dan.
--
Daniel Dyer
https://watchmaker.dev.java.net - Evolutionary Algorithm Framework for Java
Jack Dowson wrote:
(example code)
>I've tried,and the system replied:
>java.awt.event.WindowEvent[WINDOW_CLOSING,opposite=null,oldState=0,newStat e=0]
>on frame0
>and then went back to the former condition.
The 'former condition' would be meaning what?
a) The frame, on screen and visible.
b) The screen, no frame (frame exits).
>Why?
Here, it was 'b' for both Frame and JFrame.
--
Andrew Thompson
http://www.athompson.info/andrew/
Message posted via JavaKB.com
http://www.javakb.com/Uwe/Forums.aspx/java-general/200705/1
Andrew Thompson ??:
> The 'former condition' would be meaning what?
> a) The frame, on screen and visible.
> b) The screen, no frame (frame exits).
Thank you.
It was a) for me!
The frame is on screen and visible,only by kill the process can I end
the program.
Dowson.
Jack Dowson wrote: >Andrew Thompson ??: >> The 'former condition' would be meaning what? >> a) The frame, on screen and visible. >> b) The screen, no frame (frame exits). >Thank you.
>It was a) for me!
heard that not work to exit the VM and *close*
the frame.
>The frame is on screen and visible,only by kill the process can I end
>the program.
Huhh.. best stick with Swing and setDefaultCloseOperation(),
then. ;-)
--
Andrew Thompson
http://www.athompson.info/andrew/
Message posted via JavaKB.com
http://www.javakb.com/Uwe/Forums.aspx/java-general/200705/1
Hi Stefan,
Stefan Ram wrote: > "Daniel Dyer" <"You don't need it"> writes: >>It's worth mentioning the @Override annotation in this context.
> This can be used when extending classes,
> but not when implementing interfaces.
because the compiler will warn you as well, when you misspell the method
name (although the error is slightly different "class x must be declared
abstract or implement method y" or somehthing like that).
Ciao,
Ingo
>>>It's worth mentioning the @Override annotation in this context.
>> This can be used when extending classes,
>> but not when implementing interfaces.
Ingo R. Homann <ihomann_s@web.de> wrote:
>The reason is that it is not necessary when implementing an interface
>because the compiler will warn you as well, when you misspell the method
>name (although the error is slightly different "class x must be declared
>abstract or implement method y" or somehthing like that).
Unless it's a method that's accidentally provided by some parent class. Or
unless it's a method you think is on the interface and it's not. It
would be nice if @Override worked for interface methods, or if there were an
@Implement annotation to provide similar safety for interfaces.
--
Mark Rafn d@dagon.net <http://www.dagon.net/>
Hi,
Mark Rafn wrote: >>The reason is that it is not necessary when implementing an interface >>because the compiler will warn you as well, when you misspell the method >>name (although the error is slightly different "class x must be declared >>abstract or implement method y" or somehthing like that). > Unless it's a method that's accidentally provided by some parent class.
> Or
> unless it's a method you think is on the interface and it's not.
No, because, then the method on the interface is not implemented at all
and the compiler will warn you!
> It
> would be nice if @Override worked for interface methods, or if there were an
> @Implement annotation to provide similar safety for interfaces.
ACK to this.
Ciao,
Ingo
|
 |
 |
 |
 |
|
Add to del.icio.us |
Digg this |
Stumble it |
Powered by Megasolutions Inc