We Keep Coding

Drop To Frame sometimes disabled, sometimes not

I often use the Eclipse Debgugging function Drop To Frame, but sometimes it is not available when debugging. I found another question on SO and an Eclipse Help entry, which says:
Note this command is only available if the current VM supports drop to frame and the selected stackframe is not the top frame or a frame in a native method.
My problem is, while debugging the same function (its not the top stack frame, and neither it or its parent is a native method - though there is one 3 levels higher) I sometimes find that Drop to Frame is enabled and I sometimes find it is disabled.
Do you know any more limitations to Drop To Frame, which could be a reason for it not being available? Note: I use the same JVM all the time, and I can't quite imagine it sometimes supports Drop To Frame and sometimes it doesn't.

In case someone has the same problem: Since we switched from an earlier Eclipse Version (I think Luna) to Neon, the problem doesn't occur anymore. Maybe it was a bug that was fixed in newer Eclipse versions and only occured from time to time.

Sporadic GUI freeze on the (java) application start

we have a strange problem with our GUI after changing to Java 1.7.
Sometimes if the user starts our Application it seems to be freezed, but probably there is just no repaint, because if user tries for example to scroll, changes the window and comes back to application the scroll changes are visible.
And the problem will be solved if the users change to fullscreen.
I tried to search for this problem, but the only thing most related to it was an unanswered question here:
http://www.java-forums.org/awt-swing/31107-intermittent-freeze-javawebstart-swing-app.html
May be anyone of you had the problem and know the solution?

The migration to Java 7 may have exposed a latent problem in the original code. Here are some things to look at:
Some APIs, especially among the text components listed here, are no longer marked thread safe in Java 7.
You can search for EDT violations using one of the approaches cited here.
Resizing the enclosing Window generates an automatic repaint(); if your updates are otherwise correctly synchronized, you can sequence your own repaint() using invokeLater().
Verify that setVisible() is last in your initialization, after pack().

Sikuli issue - capturing an area

What I am trying to accomplish is to select an area on the screen with the mouse (outside of the may frame) and get the resulting region coordinates using Sikuli.
The code that should do this looks is below:
Screen screen = Screen.getPrimaryScreen();
Region region = screen.selectRegion("Select the area.");
What happens is that the cursor turns into a selector cross (the ones you usually see when you expect this function), but I can't select the area and actually the only way I can get back from the application is by killing it. Not too many examples I have found so I am asking for help here.
How can I make this work?
Also one other question:
I have downloaded the following script version:
Sikuli-IDE-1.0.0-Win64.zip
This means if I want to create a crossplatform solution I have to include like 6 jars? I have found a more universal Java API it seems (that is what it is called actually):
https://code.google.com/p/sikuli-api/
With all required supported OS but I can't find a single example on what I am trying to do that is similar to the little code snippet I pasted here. The sikuli script I am using now and this Sikuli API (apparently not the same) seems to be just different enough to amke this difficult.
Any suggestions? Thanks a lot in advance.

As it turns out, this only happens if I put this functionality on a Swing button's actionhandler. I have reported the bug to Sikuli and it will be probably fixed in the next release.

Java Applets not working in IE9

Is there any script or code that solves this problem?
Simply I have an image player in my web site which does not work in IE9. I know there is a solution (Java Applet Not Working (Blank) in IE9) which remove the problem, but if a user have not sufficient knowledge of how Windows works, or the web site is just play on outdoor screens, it need to be fixed with code by developer. Here is my website: http://www.interactivity.com.au/
Do you know any solution on Windows?

Since in a nutshell, the reason they're not working is that they're being blocked by a security feature, by definition there's no way for your applet to get around it. If there was, then it'd be a bug in the filter, and if such a way was found, you'd expect the filter to then be fixed to prevent it.
Add a link on your site to a set of instructions on how to fix the problem.

Problem with Painting in Java Swing App in Java 1.6

I'm working on a Swing application (currently running on Java 1.6 update 11) which has some intermittent paint refresh problems (e.g. there are artifacts etc.). This only happens to some users of our application but not others.
After doing some research, I found that setting the property sun.java2d.d3d to false may help and in fact, it helped for one of our users.
Now that some other users are complaining about the issue, I'm thinking of setting the property to false for all users.
My basic questions are the following:
What exactly is the cause of this? Is it the video card? Is it the driver? Is it a bug from Sun? (such as http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6635462) Combination of all three?
In other words, is is best to simply turn this property off or is it affecting only certain video cards in which an update to the latest driver would fix?

Java introduced in R6 update 10 a pipeline that renders graphics based on Direct3D. According to the release description here it supports only NVidia and ATI cards, which means anyone not using those cards may have a problem. Since it is a recent innovation I would suggest that anyone using old drivers for those cards may also have problems. Upgrading a video driver will probably fix the first case but not the last.
If you set sun.java2d.d3d to false the worst that can happen is that some users will not achieve the performance that they theoretically could. You will have to balance whether this is preferable to the issues that you are seeing at the moment.

Are all painting and model changing operations execute on EDT (e.g. changing TableModel etc.)?