[RESOLVED] Full Exit on MenuItem Action

[capitolc]

How do you close out an application when using a menubar?

The native 'X' button does show and I am able to close by clicking that without a problem. Here's the situation. My .jar program is executed by another application and my form/JFrame shows up as expected. When its time to exit, I click the 'X' and my form/program ends and the application running my program also exits (frees up memory). When I use my menubar to excute an exit, the form disappears due to my call to .Dispose() (there isn't a .close/.exit). It appears my program has ended, but the .jar is still running (taking up memory) by way of the application running the .jar.

So I ask, how I can I throw the System.Exit(0) when calling my actionEvent on the menubar as it works when the 'X' button is excuted??


main in main class

myFrame.addWindowListener(new WindowAdapter()
			{ public void windowClosing (WindowEvent event)
				{ System.exit(0); }
			}		
		);
		myFrame.setDefaultCloseOperation(myFrame.EXIT_ON_CLOSE);	
		myFrame.setVisible(true);
		
		JMenuBar mBar = new JMenuBar();
		JMenu mnuFile = new JMenu("File");
		JMenuItem mnuFileExit = new JMenuItem("Exit");
		mBar.add(mnuFile);
			mnuFile.add(mnuFileNew);
			mnuFile.add(mnuFileExit);
			mnuFileExit.addActionListener(new FileExit_Click());

FileExit_Click class implementing ActionListener

public void actionPerformed(ActionEvent arg0)
{
     /*placing addWindowListener here also doesn't work*/
     myFrame.addWindowListener(new WindowAdapter()
          {
               public void windowClosing (WindowEvent event) { System.exit(0); } 
          } );


     myFrame.dispose();
}

[keang]

From the Sun information on shutting down applications:

Therefore, a stand-alone AWT application that wishes to exit cleanly without calling System.exit must:
Make sure that all AWT or Swing components are made undisplayable when the application finishes. This can be done by calling Window.dispose on all top-level Windows. See Frame.getFrames.
Make sure that no method of AWT event listeners registered by the application with any AWT or Swing component can run into an infinite loop or hang indefinitely. For example, an AWT listener method triggered by some AWT event can post a new AWT event of the same type to the EventQueue. The argument is that methods of AWT event listeners are typically executed on helper threads.
Note, that while an application following these recommendations will exit cleanly under normal conditions, it is not guaranteed that it will exit cleanly in all cases. Two examples:
Other packages can create displayable components for internal needs and never make them undisplayable. See 4515058, 4671025, and 4465537.
Both Microsoft Windows and X11 allow an application to send native events to windows that belong to another application. With this feature it is possible to write a malicious program that will continuously send events to all available windows preventing any AWT application from exiting cleanly.

On the other hand if you want to forcibly close the app regardless of the state it is currently in just call System.exit(0);

[capitolc]

...wow, that was easy. I needed to kill the entire thing so System.exit() does exactly what I need!

[dlorde]

Be aware that System.exit(..) is considered the last refuge of the desperate programmer, so don't mention it at interviews without rolling your eyes and going "Tsk". If you do use it, the int argument is the unrecoverable error code - returning 0 is considered very bad form

By relieving the brain of all unnecessary work, a good notation sets it free to concentrate on more advanced problems, and in effect increases the mental power of the race...
A. N. Whitehead

[ProgramThis]

Really? I remember reading somewhere that you should use 0 when you exit the application normally and any other number (meaningful only to the calling operation if there is one) if the application exits on failure. Then again, I was using ANSI C at the time, so it may be a C thing.

[dlorde]

Really? I remember reading somewhere that you should use 0 when you exit the application normally and any other number (meaningful only to the calling operation if there is one) if the application exits on failure. Then again, I was using ANSI C at the time, so it may be a C thing.

You're right, those are the correct semantics; it's just that AIUI Best Practice design suggests that normal termination should not involve System.exit(..) - i.e. flow of execution should just terminate naturally at the end of the main(..) method. I suppose it's the same principle that says a method should only have one successful return path - the only additional returns should be short-cut precondition failures.

And with exceptions, a good application only need call System.exit(..) once, to return an error code to the OS...

Too precious? it doesn't matter - what actually happens is a matter of taste, practicality, and compromise

Computer Science is a science of abstraction -creating the right model for a problem and devising the appropriate mechanizable techniques to solve it...
A. Aho and J. Ullman