Apple JVM on various OS X version have apparently been broken in that they do not generate the WindowClosing event when they should (for example if you close an app's main JFrame using by clicking on the close button).
(in the most recent Apple Java updates you can set a property forcing the event to be generated but this is not what I'm looking for)
My problem is simple: I'd like to display a "tip" when the user closes the app. However I cannot (due to the fact that no event is generated) detected that the user closed the window.
So I thought I could use a shutdown hook:
Runtime.getRuntime().addShutdownHook(...)
However apparently creating a JFrame from a shutdown hook seems problematic: it's like if the EDT was already gone once the shutdown hook is called.
I tried several things and nothing really seems to makes sense: like my "Tip" JFrame staying all gray (despite it working fine when called from anywhere but the shutdown hook) or the program exiting immediately. I tried using a latch and waiting on the latch from the shutdown hook but it's as if the EDT wasn't there anymore.
I'm currently seriously considering spawning a second Java app just to display the tooltip as a workaround but I think it's a bit overkill (but at least it would work).
Did anyone ever try to create a window from a shutdown hook and invoke things on the EDT and are there any gotchas to be aware of? (remember that I cannot reliably catch the window closing events on OS X due to known very-longstanding Apple VM bugs).
If the window is actually closing and the application is stopping then something is calling the JFrame.dispose() method. overwrite this, and add your code there.
otherwise you can add a daemon thread that listens to the closed method on the window listener, the daemon can add the tooltip and then dispose of the window. you can delay the dispose until the tooltip is done.
I've never heard of this bug, but things can only get better now that apple isnt releasing its own jdk's.
Related
Dear all please help me
when I run the project it stills running all over the time
when I repeat running multi-times I found processor processes more then 10 project s !!!!!
NetBeans allows multiple executions of the same project at the same time. What's probably happening is that app is not shutting down when you close its main window.
The reason: closing a JFrame window doesn't necessarily shut down your application. Unless you say otherwise, the default behavior is to simply hide the window and keep the application running.
If you check the DefaultCloseOperation property of your app's JFrame, you'll probably find that it's currently set to HIDE_ON_CLOSE. Change that to EXIT_ON_CLOSE and your application will shut down when the window is closed.
Note that you can still start multiple copies of your application at the same time, if you so desire. But with the application actually shutting down when you close its window, you're now less likely to find yourself accidentally knee-deep in multiple running copies that you thought you had previously killed.
Read all about window-closing options here.
Why is it recommended to use setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE); if there are ways to explicitly close the frame?
Calling setDefaultCloseOperation(EXIT_ON_CLOSE) causes the application to exit when the application receives a close window event from the operating system. Pressing the close (X) button on your window causes the operating system to generate a close window event and send it to your Java application. The close window event is processed by the AWT event loop in your Java application which will exit the application in response to the event. If you do not call this method the AWT event loop may not exit the application in response to the close window event but leave it running in the background.
JFrame.EXIT_ON_CLOSE stops the application from running in background. For example, if you didn't use JFrame.EXIT_ON_CLOSE, if your application has an active database connection, it will stay connected. To check this, you can open task manager and see the jar file still running even if its window is no longer visible.
I started working with the new Lwjgl 3 which uses GLFW for its Display/mouse/keyboard handling and I'm really liking it! However today i hit a brick. I had a simple rendering animation going but when I dragged the screen it stopped rendering until i let go again.
According to: http://www.glfw.org/faq.html
The problem arises due to windows.
3.5 - Why does my application freeze when I move or resize the window?
The Windows event loop is blocked by certain actions like dragging or resizing a window, or opening the window menu. This is part of the design of Windows and cannot be changed by GLFW. If you wish to keep rendering during such actions, you should render from a secondary thread.--http://www.glfw.org/faq.html
Ive done multi threaded things before in Java. But im not sure what goes in its own thread for this case. Should I have the opengl code and the GLFW code in seperate threads? I'm also having trouble thinking of a way to word my concerns.
The only real restriction as far as I can find out is that GLFW needs to be in the application's main thread. This is where the OS event queue lives for GLFW and is why glfwPollEvents and glfwWaitEvents need to be in the main thread.
OpenGL rendering can be done from its own thread. glfwMakeContextCurrent ties the OpenGL context to the thread making that call. If your render function runs on it's own thread just make sure to update the context (as shown in the demo).
LWJGL Forum topic: [SOLVED] LWJGL3 Not threading as expected
LWJGL3 Multithreaded Demo referenced in the above link
No, you cannot use GLFW and OpenGL in separate threads. Both must operate in the main thread. As for the blocking, there's not much you can do about it. You'll just have to check for extended pauses between frames, (E.x. when the user moves the window.) and calculate animation, and other time based events accordingly.
I'm writing a simple app to enable adb over ethernet on startup of the android, with a cancel button to prevent the enabling of the of the adb on the network. When the pop-up for superuser appears, if clicked immediately everything is fine, but if I wait a few seconds and click ok, the display fails to update.
The onCreate uses a mHandler to start a runnable, which is used for the countdown timer. When I used a mHandler.postDelayed to try to delay past the startup process, the display is never updated. When I use mHandler.postAtFrontOfQueue the countdown display functions properly, but following the superuser dialog the screen fails to update.
The countdown timer uses mHandler.postAtTime to repeatedly call the runnable. I'm thinking I need to put something at the start of the runnable to reset the focus, but am still new to the android and not having any luck figuring out what would make it happy.
When the application is run manually, everything is correct. On a second android, everything is correct.
I've found a workaround to the problem by changing from using "android.intent.action.boot_completed" to using "android.intent.action.MEDIA_MOUNTED".
What I observed was that the boot_completed happened before the full boot was complete. Something, not sure exactly what, stepped all over everything. When I tried to sleep or launch the runnable with a timer, if the sleep or timer crossed over the time things went wrong, the sleep and timer would never return, without ever getting into the runnable. By switching to the media_mounted, whatever was stepping on things had already passed.
I had been thinking of using the startup app to execute an init.rc file from the SD, so trigging off the media mount makes sense for that need.
I made a java application that saves data to a .data file. I have a Window Listener that listens for the application to close in order to fire the code to save the data to the file. When pressing the dedicated quit button I have, or pressing the red "X" on the window, everything is fine. However, when the user opts for the command + q route things go sour. The application is quit, but the data is not saved. How do I correctly implement apple's handleQuit(Application Event e) method to fix this?
What you want in that case is a shutdown hook. A shutdown hook listens for the OS signal to close the app and is triggered when this signal is sent. A shutdown hook can run pretty much any code.
You can wire your built-in red "X" button to close the app (instead of saving the file), and the shutdown hook will catch the request and take care of saving the file.
The only caveat is that shutdown hooks are supposed to be made up of code that doesn't take very long to execute. So, the save of your file shouldn't take more than a second or two, and you shouldn't use confirmation dialog boxes that the user must acknowledge in a shutdown hook, because it can take an indefinite amount of time before the user recognizes the dialog.
The reason why shutdown hooks should be short lived is that when an application is requested to shutdown, the OS generally expects it to shutdown in a reasonable amount of time. If it doesn't, for example in Windows, the OS might display one of those, "Application isn't responding..." messages.
Finally, and you might run into this question later, you might wonder how to catch a "Force Quit" request from the Task Manager (or "Force Quit Applications" dialog on OS X). Well, you can't catch those, and you shouldn't try! While it is possible to disable things like listing your app in the Force Quit menu, this is a complete hack and should be avoided at all costs. If you're designing your app in a way that tries to circumvent options that should always be available to users and admins then that's a strong indication that your app is poorly designed, and/or a bad actor. Imagine if you installed an app that behaved in this way - wouldn't you think the programmer was being lazy or possibly malicious in trying to give their app un-killable qualities?
Also, force quitting is a forcible (ungraceful) shutdown that should only be used on applications when they are hung and won't quit normally. OSs need to have a force quit kind of option so that a user or admin has a way to kill a runaway or unresponsive app. If your users are force quitting your app they either misunderstand that force quitting isn't desirable, or there's something about the design of your app that makes force quitting more favorable than quitting your app normally. If this is the case (e.g. you hear from users that they force quit for one reason or another), it's usually an indication that portion of your app is poorly designed to match user's expectations.