Environment: Windows 7, JRE 8.65, observed with both yEd 3.14 and GanttProject 2.7.1 (also previously observed on Win XP.)
Can the program's main window take focus (not auto-raise) without being atop other windows and without clicking in it? (nothing found in 917 results from a StackOverflow search on the words "Java" "window" and "focus", though I was getting bleary-eyed by the end.)
The problem is that when I move the pointer into or across the program's window, that window does not activate, though it activates the icon in the "task bar" (which is auto-hidden.) It is clear that the program recognises the pointer's existence and focus change, but the main window never actually takes the pointer (i.e. the main window remains inactive, and requires that I click in it to activate it; which raises it, which is exactly the behaviour I try to avoid with F-F-M.)
This is more troublesome because when the icon in the task bar activates, the task bar covers a chunk of my screen and won't go away until the main program window is activated by clicking in it. Simply moving the mouse from one place to another on the screen has about a 30% probability of touching (and half-activating) one of these program windows, forcing me to locate the window, click in it, minimise it, then get back to what I really was trying to do. (Yes, my "desktop" is a jumble, but everything has its place and normally I can rapidly navigate among the dozen or so windows that are truly useful.)
Thanks for any pointers or advice. (Though suggestions that I change my behaviour probably won't be followed.)
This problem occurred to me as well. The only workaround I got so far is using JRE 6 if possible since this annoying behavior started with JRE 7.
Related
Recently, our Java application was a bit slower than usual, we just ignored it, because we use cloud DB which is a bit slow sometimes.
I used to navigate to other windows by pressing (alt+tab) in the windows machine. One day I found many JDialog boxes are opened. When we click it, nothing happens and it is also not shown. Again, when I press alt+tab, it is still here.
If I kill the application all the dialog boxes vanish. Since our codebase is huge with 5000+ Java classes, we don't know how to find this dialog box.
you can create a heap dump using jmap (jmap -dump:file=filename PID). after that you can see in the dump which of the JDialog remained in memory using the visual vm
I have a Java/JavaFX application deployed as a native install for Windows and Mac. The bundled runtime is currently 8.121. You can find the installers and the Java code here: George download
I have been using this application in the classroom weekly (with 20 children) for the last 15 months, and right from the start I have seen the following problem:
From time to time, buttons disappear. That is to say, they are simply rendered as a white rectangle, making them effectively almost invisible. Both the background and label/text disappear.
This mainly happens on mouse-over, but then does not correct itself.
The buttons are still there, and clickable.
It only happens sporadically, but it seems to recur on certain machines more than others. Windows 10 now, but used to the same happened on tiny Windows 7 machines previously.
I am not able to reproduce it myself and have never seen it on a Mac, I think.
It now also happens sometimes with other widgets/controls, and even before any user interaction.
Is there some known issue around this?
Has anyone else described something similar?
Might it have something to do with certain minor operating system adjustments?
Any thoughts or ideas would be much appreciated.
Update (2018-11-06)
Just started testing my application in Java 8 in VirtualBox with Windows 10, and I now get the rendering error myself. Hurra!
Looking into the -Dprism.xxx options, I found this article:
http://werner.yellowcouch.org/log/javafx-8-command-line-options/
Testing with -Dprism.threadcheck=true, I get a lot of
"ERROR: PrismPen / FX threads co-running: DIRTY: false" with stack traces.
Setting -Dprism.dirtopts=falsedoes not solve it for me, though.
But running with -Dprism.order=sw does. But this is not a good solution for an application that may do some demanding rendering (Turtle Geometry).
Will keep digging.
I've been having the same issue, I tried updating to Java 10 but the issue remained. I then edited the properties on java.exe and on the 'Compatibility' tab I set 'Override high DPI scaling behavior' to 'System (enhanced)' and the problem seems to have gone away (or at least it hasn't happened again yet).
I observed the same thing: Visually disappearing (but still functional) buttons and other controls (except labels) especially in areas outside the original size of the window after I have resized it manually)
In my case -Dprism.dirtopts=false reduced the problem but also didn't solve it (and was not really a satisfying solution anyway).
Additionally I observed that some TextField controls also showed rendering glitches (looked like the same text was rendered twice with a little offset). That finally put me on the right track:
It turned out to be just a missing Platform.runLater(...) around some calls to TextField.setText(...) (from another thread) for exactly these TextField controls, which was causing this (even for e.g. a Button which is at a totally different place - also in the widget hierarchy).
I know, this is probably not the answer in all cases, but hopefully it helps at least some others facing the same problem (took me a full day to find out).
Ok, so this is a really, REALLY weird issue that we're having with the application at my company. I'm going to try and describe this as best I can.
First, this is a legacy application with a Swing UI.
Second, the issue only occurs when it is compiled & run using Java 8. With Java 7 and below, this does not occur.
So, the issue: When a dialog is displayed (modal or non-modal, doesn't matter), the UI becomes unresponsive to mouse clicks. What's truly crazy, though, is the UI is NOT frozen. Hovering the mouse over something produces the hover highlight as normal. Keyboard commands are received perfectly. Mouse clicks, however, do not work.
This also only occurs on OSX. Windows and Linux don't have this problem. I'm running this on OSX El Capitan.
As far as code samples, it's affecting all dialogs across the application. JOptionPanes & JDialogs, doesn't seem to matter. Here's a simple JOptionPane declaration:
int n = JOptionPane.showOptionDialog(mcContext.getMapperView(), "xPath of dropping target can't be evaluated" +
"\nPlease, select xPath for dropped node",
"xPath calculation for dropped node",
JOptionPane.YES_NO_CANCEL_OPTION, JOptionPane.QUESTION_MESSAGE, null, options, options[0]);
This code IS being called on the EventThread, so I don't believe it's a threading issue.
I'm totally stumped as to the cause of this. So far we've ignored it by compiling and running it in Java 7, but at some point as versions progress we will need to deal with this issue more directly.
Anyone have any ideas?
Edit: Thanks for the SSCCE Idea. Now I'm more confused than ever. When I put together a quick frame/dialog demonstration, it worked perfectly. No issues. So I don't know what it is in the application that could be causing this. Any good places to start looking?
Edit 2: Wrapped one of the declarations in SwingUtilities.invokeLater, and it worked. Ok... now what could the culprit be? It's still got to be something that Java 8 is compiling different than Java 7.
Edit 3: More weird behavior. I moved my IDE into a separate "desktop" than the application it was running, and when the buggy dialog is displayed, i cant switch to that desktop. I can switch to any app on the current desktop, but not to another desktop.
Edit 4: The dialogs in question are being triggered by drag and drop actions. Not sure if that helps or not, but I do see that there is a thread in the background in the thread dump using the sun.lwawt.macosx.CDragSourceContextPeer class.
Alright, it took a while, but I think I found it. I found an OpenJDK post that seemed to very clearly describe this issue.
https://bugs.openjdk.java.net/browse/JDK-8139393
Somehow, Drag N Drop in Swing on OSX in java 8 isn't releasing its hold on the MouseEvent or Listener, so when a modal dialog is displayed the mouse isn't able to get new events through to it. Which is a crazy stupid bug, but it's there.
The solution was wrapping my code in SwingUtilities.invokeLater(...). By having the code that displays the dialogs executed asynchronously from the drag and drop code, the drag and drop operation is able to complete and release its hold on the mouse connectivity (for lack of a better description). And viola! Problem solved.
Thanks to everyone who tried to help. Hope this post helps out anyone else dealing with this issue.
Most 3D applications grab the mouse. This means the OS cursor is hidden and only the 3D application cursor is shown (and only within the application).
In case it is a game, the cursor is completely hidden so you can "look around" moving the camera with the mouse.
While I am debugging with Eclipse IDE or NetBeans IDE, the "grab mouse" event happens.
When a break point is reached, the application will not respond until, thru the IDE, I command it to continue running in the debug mode.
If I manage to make the application continue running I can release the mouse (un-grab, give back the mouse cursor to the OS) by opening a console within the application for example will make it work.
While I have no OS mouse cursor available, I get limited to the keyboard, what make things become really complicated on debugging procedure.
how to work around that?
I found that a simple trick must be used.
Add a watch that evaluates this:
org.lwjgl.input.Mouse.setGrabbed(false)
On eclipse, that watch may require to be visible or its evaluation may be skipped.
here I am looking for an IDE independent way of ungrabbing mouse.
Doing more things than releasing mouse grab:
Later on tho, it did not suffice, I wanted to do more things like auto pause the application and clear keyboard buffer, so, if the breakpoint or exception happens at any code that have no access to the function I created that does it all, that function would not work.
The workaround for that was to create a thread to monitor some variable that should be updated at the main application thread; if that variable is not updated for 1s, call the function to ungrab and etc.
I have a web application (struts 1.3, Weblogic 10.3.0, Toplink, Oracle) that has a Java applet which isn’t working in the browser (IE7/8) when the Next-Generation Plug-in setting is enabled in the Java control panel but works fine when it’s disabled. The trouble is that this setting is set to disappear in an upcoming Java release meaning that my users would have to keep using Java 1.6_xx on their workstations as they are currently. I have little influence over which version they use because they are all governed by their local IT departments across the country. So, either I have to find a simple fix to allow the Next-Generation setting to work, or we have to look at replacing/rewriting the applet with something else (but would be a last resort due to funding constraints), most likely something AJAX-friendly so as to avoid the need for a plugin. This application is quite old, written around 2001 before AJAX was really around.
The main window has a left, right, and top frame (JSP’s), as well as a center frame which is where the applet is. The applet has a main content area in the middle and a lower panel at the bottom which has some buttons. The buttons tell the content area (which is basically a treegrid) what to do (Save, Copy, change status, etc ). When I press one of the buttons the entire window (surrounding frames plus the applet itself) repeat inside the area where the applet is. It’s like a kaleidoscope or like a repeating fractal pattern kind of thing, or like when you take a picture of yourself in the mirror and you see the room repeated over and over in the mirror. In this case it repeats for each button press and the repeated set gets smaller each time. Weird!!
So, based on my research, the Java Next-Generation plugin works differently by allowing more than one process or thread whereas the classic plugin only uses a single thread. So my suspicion is that a new process is being spawned for each button press. I tried using the “separate_jvm” applet parameter but it made no difference whether it was set to true or false. I don’t see any other applet parameters which seem to be relevant.
Another idea I had is that maybe it’s something to do with the JSP frameset, maybe something like “target=_top” needs to be added somewhere…but I’m not sure how this relates to applet threads if at all.
Anyone have any suggestions, ideas or experiences that might help?
you can use velocity to handle these type of problem and it will also help you for future enhancement also.
The problem is not related to version of IE but rather to version of Java. Below excerpt from letter of certificate provider (they took it from some forum, so direct link to source cannot be provided):
For JDK version higher than 1.6.0 and below 1.6_15, you can just
clear all kinds of cache in web browser, java console and java control
panel. Then it should works fine!
For JDK version between 1.6_15 and 1.6_30, you should disable the "next-generation java" option in java control panel.
For JDK version higher than 1.6_30, you should turn on "next-generation java" option in java control panel.