I 've seen this on a user's computer:
does nothing: no exception, no stacktrace, nothing.
It doesn't work for pdf or for xls files (and probably for all other file types too).
However, if he double clicks on a pdf or xls file in Windows Explorer it opens (in acrobat reader / MS Excel).
This also works in DOS-prompt: "start C:\myFile.pdf"
Making it canonical first doesn't work either:
Java 6 update 16
Windows XP SP 3
A webstart application with all security permissions.
I've removed all JRE's and even removed the USER_HOME/application data/Sun map.
He upgraded from Windows XP SP2 to SP3 with no change.
Has anyone any idea what is causing this?
This problem has been metioned before, but they don't mention a cause or solution: http://forums.sun.com/thread.jspa?threadID=5338022
Yes, I saw the user's screen and double klik on a file in Windows Explorer opened the file correctly.
I can't write a short working example that illustrates the problem, as the same code that works on my computer as well as hunderds of others, doesn't work on his computer.
Maybe there is be something strange in his Windows XP registry. But it doesn't explain why it does work in Windows Explorer.
I also have the same problem, but with my JNI and C++ expertise, I was able to isolate the problem.
- Microsoft Windows XP, Family Edition (French), Version 2002, Service Pack 3
- JRE 1.6.0_21
In the source of the JDK6 (Src/windows/classes/sun/awt/windows/WDesktopPeer.java), the Desktop.open(file) calls the native method
For example, if you try to open "c:\helloworld.pdf",
uri.toString() = "*file:/c:/helloworld.pdf*"
if I call ShellExecute("C:\\helloworld.pdf", "open"), it works
but if I call ShellExecute(" file:/c:/helloworld.pdf", "open"), it doesn't work on my platform.
In both case, the ShellExecuteW or ShellExecuteA function of the Windows API return the integer 42 (> 32), saying that the functions succeeded. If the file object is not correct, the function should return a value <= 32.
=> The bug is not due to Java implementation, but to a bug in the Windows API.
I also tried the "ShellExec_RunDLL" entry point of the Shell32.dll library using RunDll32 utility. Both commands below are running correctly:
1) A workaround could be implemented in the JRE: use the file path without the "file:/" protocol prefix.
2) This bug seems to be present only one some version of Windows XP (to confirm).
RCardon, please don't post in threads that are long dead and don't hijack another poster's thread. When you have a question, start your own topic. Feel free to provide a link to an old post that may be relevant to your problem.
I'm locking this thread now.