We have a Java based with some native components and SWT as frontend.
We contribute our tray icon to windows notification area.
Now below is the problem
If an user is working on the application and then the system goes to sleep/hibernate
When the system wakes up it has multiple tray icons for the same application.
We have seen it happening for multiple applications. Is it a known issue or are there any workarounds ?
Regards,
Saurav
I remember this happening in Windows XP. It's not a new things and has been around for years. I suspect it's a known issue but very low priority and so has never been addressed.
I remember it happening where the software that shows the icon doesn't shut down properly and so the icon it added doesn't get cleared up. You end up with multiple icons where multiple instances of the app have been started but not shut down correctly.
The real solution here would therefore seem to be to build more resilient software that doesn't crash. Obviously debugging hibernation issues can be tricky but I'd start by looking at your own software.
Related
Users of our application have been experiencing problems with their Swing GUIs not drawing correctly.
The common link between all users with problems is that they've recently applied a Windows update. Users have reported that dialogs draw correctly on some monitors but not on others.
An example of the kind of problems we're seeing*:
Users also report dialogs which only show a frame, and are otherwise transparent. Effectively the same kind of problems you'd see if the UI thread were blocked.
What could be the problem?
*I can't post screenshots of our actual application as it contains sensitive information
Update: This issue has been fixed in update KB4039884.
This seems to be a reasonably wide-spread issue caused by a recent patch. It's not limited to Java:
It seems, that Microsoft’s Update KB4034664 (and KB4034679) for
Windows 7 and Windows Server is causing display issues with several
applications on a second screen.
Reported by Born City, Computer World, and Microsoft themselves:
If a machine has more than one monitor connected and the screen
numbering is not in sequence, some applications will experience
rendering issues.
You should be able to solve the problem by rolling back the patch. It is a security update (links above detail what is included), so if you're particularly risk-averse you may not want to do this.
Microsoft lists the workaround as:
Enable Desktop Composition (needs graphics card support).
Make sure that the main monitor is on the top left in the monitor layout.
You could also try switching to a single monitor setup, or making other changes to your monitor configuration (Control Panel > Display > Change display settings). Some reports speculate that which monitor is set as your 'main display' may make a difference.
You might also want to try the following flag: -Dsun.noddraw=true
I have a legacy Java application that uses Java 1.3
It works fine on windows Xp but now I need to make it run on windows 7.
I have installed the 1.3 jdk however when it first loads, the app won't render properly. Bits of the screen just show grey background, selecting buttons won't load a new screen etc.
I do know watching the output from the app it just purely graphics not rendering properly.
However if I press "Ctrl-alt-delete" and then just press "cancel" the software runs perfectly.
If I have a second monitor plugged in, it runs perfectly.
Has anyone got any suggestions how to make app run perfectly first time.
Thanks
Firstly, update your java, no excuses not to.
You can try the hack of resizing your component to a different size and then back again. I find this is the best way to make sure that swing doesn't do this sort of mischief with black squares here and there.
These things happen from time to time with non native tools for desktop development as opposed to those specifically designed for the targeted platform.
In Java 7 and 8 there is a bug in Swing menus that causes it to be slow when running an application remotely over X11 while other X11 applications are running. This issue was introduced in Java 7 and has never been fixed. Does anyone have any suggestions on a workaround. Using nxclient addresses this Swing menu issue, but introduces its own unwelcome issues.
The steps to reproduce the Swing menu issue are:
- run any X11 application locally with some activity
- log into a remote server using ssh -Y someserver
- execute any Java GUI application (e.g. jvisualvm) running Java 7 or 8
- select a menu and observe a several second delay in response
Just spent an entire day trying to solve the same issue. There's barely any info out there.
Local machines:
Linux FedoraCore 20, KDE desktop, NVIDIA GeForce 7300 LE
Linux FedoraCore 20, KDE desktop, NVIDIA GeForce GT 720
Running remote Java GUI over ssh, swing popups are extremely slow for PC2. Desktop freezes until popup appears. On the other hand, PC1 runs very fast/smooth, with no problems at all.
Turns out, in my case, the problem is that PC2 has 2 monitors. The closest bug report I could find is: JDK-8004103 : sun.awt.X11.XToolkit.getScreenInsets() may be very slow and it appears to be still open.
Temporary Workarounds:
In KDE, Disable second monitor, Launch Application, Enable second monitor
Work in Gnome Desktop (My Gnome environment not affected by this issue)
Launch remote Java app using Java 6 (Issue not present in Java6)
None of these are ideal workarounds, but considering that my Desktop freezes for 3-4 seconds every time I click on a menu item, they'll do for the time being.
I finally found much better workaround for this problem. When opening the SSH connection to the remote computer, set ForwardX11Trusted option to "no".
ssh -o ForwardX11Trusted=no -X user#host.domain
For me, opening a ComboBox reduced from ~14s to instantly. Unfortunately, I currently don't have any Java applications with Swing Menu installed on the server, but I think this should work for Menus too.
If you don't want to type that option every time, add the following line to ssh config file (/etc/ssh/ssh_config)
ForwardX11Trusted no
Well, there still doesn't seem to be much information out there on how to work around this problem and running an application via remote X11/xinerama makes it practically unusable. In particular, menu navigation takes an eternity. The work-around that we employed has 2 parts to it.
At the startup of your application call:
JPopupMenu.setDefaultLightWeightPopuEnable(false);
This will force the popups to use heavy weight popups. Lightweight popups make multiple calls to the X windows across the network to determine what is visible, obscurred, etc. When operating over remote X11 this becomes a very expensive call. Lightweight popups make these calls everytime the popup becomes visible. Heavyweight popups make this call when they are 1st invoked, but every successive popup action reuses the heavyweight component that I'm guessing is managed by the window manager so the menus thereafter are very responsive.
Create a new XineramaJMenu class that extends JMenu. This class must override the method:
protected Point getPopupMenuOrigin()
{...}
copy the code for this method from JMenu, but replace the line:
Insets screenInsets = toolkit.getScreenInsets(gc);
with
Insets screenInsets = new Insets(0,0,0,0);
This eliminates the getScreenInsets(...) call, which makes multiple calls to the remote X server to determine the max inset values of the child windows. We eliminate this expensive call across the network and accept a default 0 inset.
Unfortunately, this will require you to replace all instances of JMenu with XineramaJMenu, but it at least results in usable menus when running your application over remote X11.
I was able to solve this problem on a RHEL 7 system with NVidia graphics board and NVidia driver 340.96 running KDE 4.14.8 by adding this option to the Screen section of the X server config file.
Option "nvidiaXineramaInfo" "Off"
The NVidia driver manual has this to say about this option:
The NVIDIA X driver normally provides a Xinerama extension that X
clients (such as window managers) can use to discover the current
layout of display devices within an X screen. Some window mangers get
confused by this information, so this option is provided to disable
this behavior.
Perhaps KDE is one of the window managers that gets confused?
I'm working on a Java program that is intended to run in full-screen mode. It uses numerous of customized Swing components and Java2D-drawn components that need to be updated and repainted several times a second. And it was working relatively fine on my underpowered work PC.
But then I tried it out at home on my much more powerful PC. And it ran noticeably slower. Triggering an event that should have instantly updated about 20 different screen elements instead caused an effect where each element seemed to take at least a quarter second each to repaint itself. So instead of instantaneous changes it was taking 5 seconds to complete each screen change.
I thought that maybe I was trying to repaint too often or in the wrong manner. But after experimenting a bit with other ideas, on a hunch I let the application start up in a windowed mode instead of in full-screen mode. And with that one change, everything started to work perfectly fast and smooth.
So I suppose there are really two issues here: Why does full-screen mode cause this problem? And why is it only causing this problem on my faster computer? I do suspect there's an OS-related bug. My slow work computer is Windows XP while the home one is Windows 7. I saw in other threads that Aero on Win7 can cause Java speed issues so I tried disabling it. That did cause a small speed improvement but it still wasn't as smooth as when I ran in windowed mode. Has anyone else had performance issues running full-screen Java apps on Win7? And if so, is there a work around?
I found the solution. I stumbled upon Oracle's Java System properties page (http://docs.oracle.com/javase/1.5.0/docs/guide/2d/flags.html) and figured there might be something useful there. While using the trace command I noticed that there were a lot of Direct3D references. Since nothing in my app is 3D, I thought that strange. So I added -Dsun.java2d.d3d=false to my Java command line. As the page says that option will "turn off the Java 2D system's use of Direct3D". And it worked like a charm. Now it runs perfectly smoothly on my Windows 7 machine in full screen mode.
I am creating an application that is essentially a financial alerts site. I am a basic level Java programmer, and I have created some of the logic for alerts in Java.
I want to be able to have pop-ups appear on the desktop whenever something "interesting" happens (interesting depends on %change, liquidity and a few other simple factors).
What is the best combo of technology to implement something like this?
I would use the java.awt.SystemTray in Java SE 6. It's cross-platform and pretty easy to use.
Although some people hate the balloon notifications in Windows, they're the least obtrusive popups, since they can be ignored by the user or easily dismissed. Most importantly, they can't be missed by the user who has been away from the computer, because balloons (at least in Windows XP/Vista) use system idle timers to determine when's the right time to disappear.
Some prefer more traditional toast notifications, similar to those shown by Outlook - they show up and slowly fade out, giving the user some time to interact with them if needed.
I had the same problem and finally solved it using an undecorated, alwaysOnTop window.
And thanks to this blog entry I found the TimingFramework, and now it even is translucent, fades in and out, goes 100% opaque on mouse over etc. In conjunction with the SystemTray and TrayIcon the behavior is nearly as that of Outlook.
Oh, I have to note, that other than the second link, I do the fading out with
AWTUtilities.setWindowOpacity(window, op);
You could write a java program that resides in the system tray, but I am not sure if there are cross platform compatible ways to do this. maybe you have to use a platform specific library for Win, Mac, Linux, ...
I'd just create a message window and animate it. Then add SystemTray support and voila, you're done.
In Delphi you can do that pretty quickly, but you can't easily reuse your java logic
You can just run you program in "silent" mode, without creating any windows by default, maybe just a little icon in the taskbar which when double-clicked will open a settings window. The program will be running in the background and creating windows with the set focus whenever an event happens.
But in my opinion, a slide window or at least a balloon tooltip is a better idea.