This content has been marked as final. Show 4 replies
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:
rundll32 SHELL32.DLL,ShellExec_RunDLL "C:\hello.pdf"My conclusion:
rundll32 SHELL32.DLL,ShellExec_RunDLL "file:/C:/hello.pdf"
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).