I have a page with multiple applets (yes, it's old). One of these applets overrides the stop method, as follows:
#Override public void stop() {
System.out.println("Stop called!");
}
But, when I do this, nothing is displayed in the console (yes, the java console) when I switch tabs, or do anything else that should call stop(). The same problem is happening with overriding destroy(). However, the start() and init() functions work as expected.
My applets are extending another class, which in turn extends JApplet. I did this to give all of my applets access to specific functions (defined in this in-between class). These applets also create other threads for repetitive tasks, but I don't think that should affect the life cycle methods. I'm not sure where to look at this point, is it possible that the focus functions or something else like that is preventing the lifecycle methods from executing, or does having multiple applets on one page cause problems with these methods? Thanks beforehand.
EDIT: I have posted a SSCCE on my server to show this behaviour Click here to run and Here to dowload sources, it's a simple applet that starts a thread, which calls a method in the parent applet that opens a JDialog. You'll notice that you can close the browser tab while the dialog is open (as long as there are other tabs open) and neither the stop or destroy print statements will occur in IE10. On top of that, the JVM keeps running, and the Java console does not close. However, if you acknowledge the pop-up before closing the browser window, everything functions as expected.
So, the question then, is if someone closes the browser window while a popup is open, how do I kill the extra thread, and the pop-up itself?
The JDialog mentioned is created using JOptionPane. Quoting from the javadoc
All dialogs are modal
Modal dialogs effectively block the applet preventing the stop and destroymethods in the applet from being called. You could simply make the dialog non-modal
popup.setModal(false);
After downloading and expanding the Zip, and turning the 2 sources into an SSCCE (an SSCCE is one source file by definition), I noted the same behavior in IE9.
It seems to me this is yet another example of a browser/JVM interaction bug. In FF the user is unable to close the page or change tabs when the dialog is open. That leads to a behavior that is as we'd expect, since the dialog must be closed prior to the applet tab being closed (or tab change or the browser being closed).
In IE9 (and 10, according to your report), the page can be accessed despite the visibility of the dialog, leading to all the problems.
Unfortunately the only work-around I could think of, didn't (work). Sometimes the necessary event can be detected by a ComponentListener, but in this case, it does not fire on closing the tab or changing tab.
So, I suggest you search the bug database for anything similar. If you find nothing, raise a new report and see what Oracle has to say on the matter. If it is a bug and they think it is the fault of IE, they can take it up with MS.
I switch tabs, or do anything else that should call stop(). The same
problem is happening with overriding destroy(). However, the start()
and init() functions work as expected.
Life Cycle of an Applet Doc page says:
When the user leaves the page, for example, to go to another page, the browser stops and destroys the applet. The state of the applet is not preserved. When the user returns to the page, the browser intializes and starts a new instance of the applet.
So yes I am having the correct result when i try to change the page on which applet is running, the stop() and destroy() method gets called and stopping and destroying gets printed. If by switching the tab you are meaning selecting one tab among the opened tabs, this is not to cause stop() and destroy() get called. However if you run JApplet directly from an applet viewer using Netbeans/Eclipes you will see that window state change(e.g., iconified, normalized) will cause stop() get called. destroy() will be called if you close the JApplet viewer.
You'll notice that you can close the browser tab while the dialog is open (as long as there are other tabs open) and neither the stop or destroy print statements will occur in IE10.
well i have tested with IE9 as i don't have IE10 now, i noticed in IE9 unlike in Firefox that the JDialouge lets switching tab among the opened tabs but it let neither the browser nor the page containing the applet get closed until acknowledging it. So it has something to do with IE10. you can try to use javascript to call an applet function to force it to be exited on window close event. I am not sure about this though as i mentioned, i don't have IE10.
On top of that, the JVM keeps running, and the Java console does not close. However, if you acknowledge the pop-up before closing the browser window, everything functions as expected.
I am a little bit confused here. Actually both Firefox and in IE9, i have experienced that after closing the page containing JApplet, jp2launcher.exe takes at most 2 mins time to exit itself and java.exe. In the mean time if you reopen the page containing the applet, it will start instantly without asking for any permission as it would ask first time when it got loaded.
Related
So, I made an applet game and put it on a webpage. I noticed that the sound kept playing after I closed the page that the applet was in. I did some research and found out that the applet keeps running, even after the page closes. I read that you are supposed to use the void destroy() and void stop() methods to dump all resources. Is there a proper way to completely stop the app? Currently I just have it create a nullpointerexception to crash the app upon closing.
The destroy methode is there for this use, i would just use it, you can make sure it gets called when the applet is finished, you can also call it in the finalize section like:
public void finalize () {
destroy();
}
I started writing a small program to learn a bit more about java and try to design my layouts by hand without always using NetBeans.
Thing is, when I run my project and close it, it won't stop running in NetBeans, so everytime I re-run it creates another run. By searching and looking at another GUI I had created using NetBeans I thought adding the
setDefaultCloseOperation(javax.swing.WindowConstants.EXIT_ON_CLOSE);
would do the trick, but I guess I am wrong.
Can someone please explain me what I should do?
Here is a SSCCE of my programa: http://pastebin.com/QhKpwdDw
Thank you very much in advance!
You might want to take a look at this question: How to close a Java Swing application from the code, as it deals with closing the application in general and also how to ensure it completely terminated.
But to answer your question quickly, there are a couple of options.
Option 1
Since you are extending JFrame in your class, you can just use EXIT_ON_CLOSE to quit.
setDefaultCloseOperation(EXIT_ON_CLOSE);
NOTE: EXIT_ON_CLOSE exits all JFrames in your application, not just the one it is applied to.
Option 2
This is most likely not the answer you want, but DISPOSE_ON_CLOSE will close only the JFrame you are applying it to.
If you have multiple JFrames open, or if you have any other Threads, they will keep running and the program will not end. But if you only have one Thread and one JFrame, this will close the application.
setDefaultCloseOperation(javax.swing.WindowConstants.DISPOSE_ON_CLOSE);
My Preference
I would go with Option 1, disagreeing with everyone else. It is directly tied to JFrame and not dependent on WindowConstants, which makes things cleaner and more reliable. But more importantly, it closes all of the windows, not just the one that you apply it to.
Even though it looks like you only have one window, you may have other internal Threads elsewhere in your program that NetBeans is throwing in there.
To be sure everything closes, you want to use EXIT_ON_CLOSE.
Extra Information
For a discussion on how DISPOSE_ON_CLOSE and EXIT_ON_CLOSE differ: http://www.coderanch.com/t/340183/GUI/java/DISPOSE-CLOSE-vs-EXIT-CLOSE
Documentation on JFrame's EXIT_ON_CLOSE: http://docs.oracle.com/javase/1.4.2/docs/api/javax/swing/JFrame.html#EXIT_ON_CLOSE
Documentation on DISPOSE_ON_CLOSE and other WindowConstants: http://docs.oracle.com/javase/1.5.0/docs/api/javax/swing/WindowConstants.html#DISPOSE_ON_CLOSE
setDefaultCloseOperation(javax.swing.WindowConstants.DISPOSE_ON_CLOSE);
http://docs.oracle.com/javase/1.4.2/docs/api/javax/swing/WindowConstants.html#DISPOSE_ON_CLOSE
DISPOSE_ON_CLOSE
public static final int DISPOSE_ON_CLOSE
The dispose-window default window close operation.
Note: When the last displayable window within the Java virtual machine (VM) is disposed of, the VM may terminate. See AWT Threading Issues for more information.
See Also:
Window.dispose(), JInternalFrame.dispose(), Constant Field Values
Try this...
Place it inside the constructor of your JFrame or the class which extends JFrame
setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
As you can see here (setDefaultCloseOperation doc) you can use DISPOSE_ON_CLOSE if you want to trigger a window listener (for example to close a database connection).
In such a case it make sense to choose DISPOSE_ON_CLOSE instead of EXIT_ON_CLOSE.
PS : Don't forget although to add a System.exit(0) at the end of the window listener code, so that the application exits.
I'm having a small problem with the Android app I'm designing.
I need to run some code whenever either of these 2 events happen:
1. The app is NOT running in the background, so the user launches it.
2. The app IS already running in the background, so the user is really
just re-opening it.
(I only need to run the code once, not twice.)
No matter where I put the call to my code (onCreate, onStart, onRestart, onResume, etc) I always have undesired affects:
A. My code gets run twice when #2 happens.
B. My code runs even when the user is just moving from
MAIN to a SUB-ACTIVITY, then back to MAIN again.
C. My code doesn't run at all.
Isn't there come kind of distinction I can make to determine: onCreate() and onRestartingFromBackGround()?
I thought I could use onRestart(), but I was VERY surprised to see that onRestart() runs even just when I do #B. (Is #B really considered a "restart" of my app????)
From a pure java standpoint, you could use a loading thread for when the icon is first pressed. This loading thread can poll the phone to see if the main activity thread is currently running or not, then from your loading thread, move to the correct piece of code. For ANDROID, I THINK, that you will poll the process name, or process ID...anyone ever poll the OS for processes??
I am calling a thread in JSP page and that thread keeps on running. I want this thread to terminate when I close the JSP page. Wow would that be possible ?
my code put it in body tag JSP:
<%
Thread Ping=new PingThread();
Ping.Start();
%>
Thanks in Advance
You mean close it when the user closes the window? There is no event fired for that, so you can't do it. You could do that via JavaScript by making an Ajax call when the user closes the window, but it's probably not going to work anyway.
The doubt that comes to mind is: why would you do such an horrible thing as starting a thead in a JSP page? By spamming the F5 button someone could obtain the easiest DOS attack of the history! Rethink your application to avoid such a solution (launching threads blindly on request, not just the fact that you do it from a JSP).
If you start a thread from a JSP, it is to impossible to guarantee that the thread will be stopped when the user exits the page.
No notification is sent from the client to server when the user closes or moves away from a plain HTML page. None whatsoever.
You could include some javascript in a web page to perform an AJAX call to your server when the user closes the window or moves to a different page. However, there are scenarios where call won't get made; e.g.
the user's machine dies,
the user's browser crashes,
the user has javascript turned off,
the user sets a breakpoint in your code,
etcetera.
And even if the call is made, there's no guarantee that it won't get lost due to some transient networking problem.
The end result will be that your server has an orphaned thread that will keeping doing whatever it is doing (in this case, pounding some other machine with ICMP packets) until you kill your web container.
That's a really, really bad idea.
You can use the Javascript beforeunload or unload events to determine that the window is being closed, though which one you use and how depends on precisely what it is you want to do.
As Anthony Grist's answer says (sort of), you can embed javascript in your web page to be executed when the browser detects that the current browser window is being closed. Refer to this page for more details about DOM Events and their handling.
Notes:
This stuff works whether or not the page is a JSP. (For instance ... it would work if the page was plain HTML ... provided that there was something on the server end to deal with the notification.)
This event handling is performed in the users web browser.
The server side doesn't get told about the window closing, unless the event handlers send an (AJAX) request to the server to tell it.
As I said in an answer to a previous question, there event handling can be disabled on the client side by the user.
As I said in an answer to a previous question, there is no guarantee that the AJAX request will actually make it back to the server.
All of this adds up to the fact that any server side handling of the window close event is unreliable. And there's no solution to that. Not in theory, and not in practice.
you could enclose the above in another loop which is set to true by the jsp page throuh ajax call on a time to time basis. if the jsp page is not setting the value to true then you can safely assume that the browser is closed. But you would need an identifier for your thread like say session id or ip of the user.
I'm new to advanced programming - but from what I've read, all my android programs are on one thread.
This means, only one line of code or method/function can be executed at a time before moving on to the next line (that's what I thought anyway).
However, I'm using a custom dialog to develop this application and yet, the program continues even after the dialog has ran. I'd like my program to wait for the dialog to close so that I can receive the input and manipulate it.
This seems fairly straightforward when programming in Java (e.g. the Scanner tool waits for the user input before proceeding as opposed to running the code following it while it waits for user input).
How can I do this?
Everything does happen on one thread unless you explicitly tell it not to. However, showing a Dialog happens asynchronously. Basically, when you ask the Dialog to show, it adds that information to a list of UI events that are waiting to happen, and it will happen at a later time.
This has the effect that the code after asking the Dialog to show will execute right away.
To have something execute after a Dialog choice is made, add an onDismissListener to the dialog and do whatever it is you want to do in onDismiss.