I face a really strange problem. The problem is that sometimes the cursor does not listen to mouse, it become suck on the field and does not move to any other field when using mouse navigation but navigation works as expected when using the tab key.
Has anybody else faced the "Sticky Cursor" problem? Oracle support says, that problem is fixed by installing newest Java update, but it didn't help.
I understand the problem you are facing. The last Oracle Forms application I worked on 2 - 3 years ago was plagued by the same issue.
I spent a long time working with Oracle Support investigating the issue but even after applying successive Oracle Form patches, later versions of the Java Runtime Environment and code changes to the Forms the problem remained.
In case it is of use here is a link to question I raised on the Oracle Forms OTN Forum asking if the problem remained on Oracle Forms 11g.
Unfortunately I was never able to resolve the problem. I hope you have better luck.
There are a few different causes for this to happen.
1) You use timers in your application. Just avoid using timers if possible this is a main cause of having problems with the mouse focus.
2) Some versions of java or jinitiator have also problems with the mouse focus. So try to use the latest versions of java 6 (version 24 or above or something like that), you can also use java 7 of course.
3) There are also a few patches of the application server to fix mouse focus problems. You have to check them all. If the right ones are installed this should fix all your problems.
I have the same problem with the "Sticky Cursor" and I tried (just for testing) the following:
If the form has Required Fields, just change the Required property from YES to NO.
If the form has Radio Buttons no visibles, make it visibles.
Try this only to testing purpose and tell me if works because I do that and in some cases works for my apps.
Related
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).
Has anyone else had this issue? I've looked around and couldn't find anything substantial. It looks like this has been reported to NetBeans under various circumstances, but doesn't seem to be a general problem and doesn't seem to have been fixed.
I'm using a MacBook Pro with the Force Touch trackpad (the one with haptic feedback and force click), macOS Sierra, the latest version of NetBeans, and the latest JDK. Whenever I right click on pretty much anything (a file, an object in the GUI editor, etc.), the right-click context menu flickers for a fraction of a second and then disappears. It seems to be very random; sometimes if I keep right-clicking several times in a row, the menu stays put, but the amount of times I have to do this varies quite a bit, if it even works at all.
I've been able to narrow it down to clicking the trackpad with 2 fingers vs. tapping it with 2 fingers. It seems to work fine when I tap the trackpad, but there is a brief delay in the context menu appearing, which is mildly irritating. Clicking the trackpad makes the menu appear instantly, but is what causes this to happen.
My thinking is that the IDE thinks I'm trying to scroll (same 2-finger gesture) at the same time I'm trying to right-click, which is not what I'm trying to do.
I have no idea what caused this issue to happen. I've been using this setup for weeks with no issues, and it just started happening today. Reinstalling NetBeans and even reinstalling the operating system hasn't solved it (yeah, complete waste of time).
Has anyone else encountered something like this? I'm not sure how to fix it other than by tapping the trackpad instead of clicking it, which causes a slight delay in the menu appearing.
I've encountered this and had resorted to using a mouse (when possible) to avoid this problem.
A related JDK bug and root cause JDK bug describe the likely cause which is a precise scrolling introduced in Sierra that caused a fast scrolling in old applications including Java. Changes to fix this in the JDK combined with later Apple Sierra fixes introduced further issues that required additional JDK changes.
A related NetBeans bug points to a tweet that indicates the actual fix should be available in JDK 8u152 when it is released.
Updating to this version or later should resolve the issue.
See also: JDK 8u152 release notes and bug fixes that indicate the root cause bug JDK-8173876 fix is present.
I've also noticed the current Oracle JDK + Netbeans bundle is only at JDK 8u151. The Netbeans.org download site doesn't specify which JDK version is bundled in its Java variants.
I'm working with GuideWire - it's an out of box online insurance implementation. It's java based and has its own IDE. Firstly DCEVM worked perfectly, increasing my productivity dramatically. But couple days ago, it has stopped working, supplying me with
"Classes hasn't been reloaded as coderedefenition is disabled".
I've already tried everything and asked everybody for help, but nobody has faced this problem.
More than likely this is because the version of java you have started the app server with is now different and doesn't have the DCEVM applied to it.
You need to double click and run the applicable dcevm.jar and then it will throw up a UI for you to view and select the appropriate JDK's to apply the Dynamic Code Evolution VM changes onto.
Full video showing how to do that is here https://www.youtube.com/watch?v=eLFxCRaVh-g
I have one program, I maintain, that was originally written in Oracle Forms 6i. A while ago I migrated it to 11g. Our users access this Oracle Forms program through their Internet Explorer browser on their Windows 7 machines.
The problem has been that the program only seems to run well for our users, when they have Java 6 Update 45, installed on their machines. Going to a newer version causes problems.
Today, I wanted to get this resolved, so I updated my PC to Java 8.31, and attempted to access my Oracle forms program using IE. (Thanks to Viewing oracle app and getting: java.lang.ClassNotFoundException: oracle.forms.engine.Main I was able to get the form running again in my web browser.)
When my form ran, I found the tab key wouldn't advance to the next field on the login dialogue box. But after I logged in the tab key worked. (The tab key initially not working is a small thing, but it has really annoyed some of our users.)
I then used several different forms. Some worked just fine, no problems. But then when I clicked a button, on one form, it would endlessly try to complete a request; to the point that I couldn't even close the web browser to stop it. (Finally I just used task manager to end my web browser’s process.) This seemed to go in line with what some of our users have reported: (when attempting to use the latest Java) that the Oracle forms application just stops working completely after a while.
Because of these issues our users want to keep Java 6 Update 45 on their machines. I know this is a major security hole, but I haven’t quite nailed down what the solution to it is.
Has anyone else had a similar issue? We're running Oracle Fusion Middleware 11; specifically Forms Services version 11.1.2.0.0
Thanks.
Well this may not be a question that needs answering after all.
I've done some more testing since asking this. Besides the login dialogue box (not responding, as it should, to the tab key) everything else works just as it should.
I still have one form that hangs; but that’s all (and it may be caused by something else). All my other forms seem to work just fine.
I talked with one of my co-workers, and I realized we really need to investigate and determine what version of Java our users really are using. They may not have used the most recent version of Java; which I used with success, today. Or some may be already on it; and that's why they aren't complaining.
At any rate more research, is needed on my part. Thanks to all who read this. If any of you have had similar experience in something like this, still feel welcome to answer/comment.
We have a problem in our swing based application since we've upgraded our java version from 6u5 to 6u18 (The application runs over WinXP).
Our application contains a Canvas object which resides in a JFrame. The application draws things on the canvas.
Every time we drag a lightweight swing object (popup or another frame) over the canvas, it has a refresh problem.
It blinks - becomes black. The problem only resolves after we move the swing component away from the canvas and click on it again.
We think this problem is related to the fact the the canvas is a heavyweight object.
And we know there were changes done in the new versions of java on the mixing of heavyweight and lightweight objects issue.
Some more details:
1) Our problem reproduces in java 6u14 and 6u16.
2) Everything works fine in java 6u5.
Another strange thing:
We have 2 types of stations running our application.
The first type has a ATI FireGL7100 PCI-E graphics card. The second type has a Matrox G450 PCI graphic card.
The problem does not reproduce on the Matrox based station in any java version.
One more thing:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6829858 - looks similar to our problem.
Is our problem familiar?
Do you have any suggestions (workarounds, ideas how the difference in graphics cards is connected to this problem)
Hope I was clear enough,
Yoav
The article Mixing heavy and light components describes how support for this changed in JDK 6 update 12. The two video cards may handle Z-order differently. Any chance your code has a workaround that's no longer needed?
We had problems w/ HW/LW mixing from 6u14+ (the fixes that breaks everything is in 14). Our problem was in a thirdy part library (JIDE) and they ended up fixing the problem on their end.
My suggestion is avoid HW where ever you can. You can get very decent performance out of LW if done correclty. What are you drawing that needs to be HW?
I don't know if this is relevant to anyone else, but we've found a workaround/fix for our problem.
We've set the system properties sun.awt.noerasebackground and sun.java2d.noddraw both to true. That eliminated our issue.
The only problem is that I'm not sure what other problems might rise from setting those system properties.