Datei mit dem Standardprogramm öffnen funktioniert nicht

[java123]

Hallo zusammen,

ich habe in meiner Applikation den Aufruf um ein File mit dem Standardeditor zu öffnen.

Desktop.getDesktop().open(fileToOpen);

Dieser Aufruf funktioniert bei acht Mitarbeitern, nur bei einem nicht. Es passiert rein gar nichts.WIr sind hier alle im selben Büro, haben dieselben Laptops und gleiche Installationen drauf (WinXP, SP3 und JRE 1.6.0.10).

Desktop.isDesktopSupported();
Desktop.getDesktop().isSupported(Desktop.Action.OPEN);

liefern beide true zurück bei diesem Mitarbeiter.
— Andere Methoden wie mail() und browse() funktionieren, edit() allerdings auch nicht.
— Throwable catchen nützt nichts, ich bekomme keinen Fehler
— Im Task Manager ist kein Prozess des verknüpften Editors zu sehen, es wird also nichts gestartet
— Den Fehler bemerkt haben wir bei «.txt» Dateien, diese Dateiendung wird bei diesem Benutzer standardmässig mit Codewrite geöffnet. Die Dateiendung mit gar keinem Programm zu verknüpfen, Ultraedit, Notepad und noch einigen anderen haben auch nicht geholfen. Auch mit z. B. «.xls» Dateien, die mit MS Office Excel verknüpft sind, funktioniert es nicht.
— In der Registry haben wir keine Anpassungen gemacht, welche und wie die Parameter der exe übergeben werden. Dia Dateitypzuordung haben wir immer über den Windows Explorer geändert.

Runtime.getRuntime().exec("notepad" + fileToOpen.getAbsolutePath());

oder irgendein anderer Befehl funktioniert.

Danach habe ich ein bisschen tiefer gegraben und per Google die DLL Aufrufe

rundll32 SHELL32.DLL,ShellExec_RunDLL <file>
rundll32 URL.DLL,FileProtocolHandler file:<file>

gefunden. Einer der beiden wird wahrscheinlich von Java bei der Windows Implementation schlussendlich aufgerufen. Diese kann ich per cmd und auch von Java per Runtime#exec() ohne Probleme bei diesem Benutzer aufrufen. Die Shell32.dll ist genau die gleiche wie bei mir und alle Dateien im JRE Verzeichnis sind laut einem Binärvergleich genau gleich, er hat die Java Installation also nicht putt gemacht (neu installieren können wir leider nicht einfach, aber es sollte alles korrekt sein).

Ich bin jetzt soweit, dass ich halt den rundll32 Aufruf implementiert habe, da die Applikation sowieso nur auf Windows läuft. Die Lösung des Problems würde mich jedoch doch noch interessieren, da ich viel Zeit in die Fehlersuche investiert habe. Hat noch jemand eine Idee, was bei diesem Benutzer anders sein könnte und den Fehler verursacht?

Ich habe noch eine andere native Implementierung der Shellexec für Windows gefunden: http://www.heimetli.ch/shellexec.html. Der Aufwand, um das noch zu testen, wäre für mich wahrscheinlich zu hoch, da ich keine Ahnung habe was ich wie ersetzen müsste etc. Keine Ahnung also ob das funktionieren würde.

Besten Dank.

 

[mccae]

Huhu,

Hast du auch wirklich genau überprüft, ob OPEN mit der entsprechende Anwendung verknüpft ist?

Schau mal hier:


Hast du auch die Registryeinträge unter HKCR\.txt verglichen?

Soweit ich weiß, führt Java auch nur einen einfachen ShellExec mit OPEN aus.

Ich selbst benutze jedoch eine eigens geschriebene JNI .dll, da ich auch öfters etwas "Als Administrator" starten muss (mit "runas").

Gruß,

 

[java123]

Jup ist es und auch die Registryeinträge sind bei mir und dem anderen Mitarbeiter gleich.

 

[mccae]

Hm,

Warum es über einen Umweg dennoch funktioniert, ist mir nicht klar.
Wenigstens funktioniert's über rundll.

Allerdings würde es mich interessieren warum das Ganze nicht funktioniert.
Wenn man das JDK mit den Sources installiert, kann man im Debugmodus die Aufrufe bishin zur nativen Methode verfolgen und analysieren.

Gruß,

 

[vfl_freak]

Moin,

Runtime.getRuntime().exec( "notepad" + fileToOpen.getAbsolutePath() );

nur so eine Idee: sollte nicht zwischen Anwendung und dem Dateipfad ein Blank stehen

Gruß
Klaus

 

[mccae]

Huhu,

nur so eine Idee: sollte nicht zwischen Anwendung und dem Dateipfad ein Blank stehen

Der TE hat ja gesagt, es funktioniert auf diese Weise.
Er hat anscheinend beim Erstellen dieses Beispiels einfach nur das Leerzeichen vergessen.

Gruß,

 

[java123]

Huhu,
Der TE hat ja gesagt, es funktioniert auf diese Weise.
Er hat anscheinend beim Erstellen dieses Beispiels einfach nur das Leerzeichen vergessen.
Gruß,

Korrekt, habe ich einfach vergessen und über den IE und FF am Arbeitsplatz kann ich nicht bearbeiten, die Browser sind ewig am Laden wenn ich «Bearbeiten» anklicke.

Bis zum WDesktopPeer#ShellExecute(URI uri, String s) Aufruf konnte ich es noch nachverfolgen und die dort übergebenen Argumente waren beim anderen Mitarbeiter und mir gleich. Danach wird die native ShellExecute Methode aufgerufen. Ich habe noch ein kleines VBA Skript (Applikation oder was es auch immer ist) geschrieben und auch ein ShellExecute Aufruf mit den gleichen Parametern durchgeführt

Sub foo()
  Dim Retval As Long
 
  Retval = ShellExecute(0, "open", "K:\temp\foo.txt", _
    "", "c:\", SW_SHOWNORMAL)
 'Fehlerhandling entfernt

End Sub

Private Declare Function ShellExecute Lib "shell32.dll" Alias "ShellExecuteA" ( _
  ByVal hwnd As Long, _
  ByVal lpOperation As String, _
  ByVal lpFile As String, _
  ByVal lpParameters As String, _
  ByVal lpDirectory As String, _
  ByVal nShowCmd As Long) As Long

Unterdessen bin ich mir nicht mehr so sicher, was ich damit testen wollte, jedenfalls funktionierte der Aufruf.

Danke für eure Hilfe, aber ich glaube kaum, dass noch eine Lösung gefunden wird :/