i build a process for run an exe file from java app so run with start() then my frame freezes. It's just becoming a picture. I can't even close it with X. When i minimize the frame and open it again i see darkness in frame. My threads running in background, i can see from output but why my frame freezes?
i build a process for run an exe file from java app so run with start() then my frame freezes
Probably because you start the process on the Event Dispatch Thread and the process is blocking the Thread which means the GUI can't respond to events or repaint itself.
The process should be started in a separate Thread. Read the section from the Swing tutorial on Concurrency for more information.
Could you provide some code, the problem could be a number of issues so it would help cut down on some of them.
I would suggest checking that you haven't suspended/slept any of your threads.
Related
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.
When I run a Java program with a GUI (e.g. a simple JFrame) and then ending the X session (logout), my Java program is terminated. Java programs that don't use a GUI keep running.
There is nothing wrong with that, but I'd like to know how the program is terminated. I don't get messages about uncaught exceptions or other issues. The exit code is 1. If the prog was terminated by a signal, the exit code would by 128+signal (afaik).
Can someone shed some light on this issue. Can I somehow prevent program termination or control the exit code for that case?
[Edit]
I'm aware of the defaultCloseOperation. I'm using EXIT_ON_CLOSE. But this would lead to a call to System.exit(0).
I also added a WindowListener to monitor which of its functions is called when my program ends. When I finish the program by clicking on the window-X, the function windowClosing() is called. When I logout and finish the X-session so that my program is terminated, no WindowListener function is called. My program just exits with exit code 1.
When I run a Java program with a GUI (e.g. a simple JFrame)
I don't know how X-session works, but when using a JFrame you need to be aware of the frames
setDefaultCloseOperation(...);
method. When EXIT_ON_CLOSE is used, the JVM will be exited right away.
When DISPOSE_ON_CLOSE, the JVM will be exited if it is the last frame open and there are no other Threads running to prevent the JVM from closing.
Coming from a WPF world, I am having a hard time implementing some basic stuff in Java.
I need to execute a *.JAR file from another java GUI application. This JAR file takes minutes to finish, and I want the GUI not to freeze.
So, my initial solution would be: create a SwingWorker class to call a command line in background.
My main concerns are:
I need to get the console output from the *.JAR file and show it in the GUI. Is it possible to update the GUI from a background thread?
Is it possible to cancel the thread from a user input?
How do I get notified that the thread is finished?
Is my solution a good one?
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.
I have the main thread from which I start a window using invokeLater. I run my application from command line. So, when application is running I see the window and my command line is "blocked" by the application.
I can stop the application either by closing the window (as a result the command line is unblocked) or by typing Ctrl-C in the command line (as a result the window disappear).
I wanted to be able to stop the application by clicking on a button in the window of the application. I used setVisible(false) for that. But in this way I can achieve the goal only partially. My window really disappear but the command line is still blocked. So, the software is still running.
Well, I assume it's because some other threads are still running. But how can I easily close all these threads (like I do by closing the window of the application manually).
System.exit(0);
If it's a JFrame you're showing, you can tell it to exit the app when the frame is closed - the default is to just hide the frame:
myFrame.setDefaultCloseOperation(JFrame.EXIT_ON_CLOSE);
This will exit the app if the user closes the window (top right [x] button often) , in addition you could have a Quit button whose event handler closes the window using myFrame.dispose();
You must finish all threads in order to stop your application. Just hiding the GUI will not finish the AWT-Thread. Have a look at the API of the GUI classes you use like the dispose-methods.
Try Window.dispose()