JFileChooser setCurrentDirectory() - Verzeichnis relativ zum Code/binary

[Mappenz]

Hi,

ich möchte ein Verzeichnis im für einen JFileCooser vorgeben.

		try {
			File f = new File(new File(".").getCanonicalPath());
			chooser.setCurrentDirectory(f);
		} catch (IOException e) {
			// TODO Auto-generated catch block
			e.printStackTrace();
		}
		int returnVal = chooser.showOpenDialog(frame);

Meine Verzeichnisstruktur sieht so aus

C:
|-...
|-benutzer
          |
           ...
              |-workspace
                         |-Project                           
                                 |-src
                                 |-bin
                                 |-icons
              |-Dokumente
|-eclipse

mit dem Punkt

File f = new File(new File(".").getCanonicalPath());

komme ich ins eclipse verzeichnis. Mit "/icons" mysteriöserweise nach Dokumente. Ich will aber nach icons.

 

[Pepe Rohny]

versuch's doch mal mit

File f = new File(".")

is' nur so'n Vorschlag ...

 

[Mappenz]

In jedem Fall ne gute Idee. Aber bringt leider auch nicht den gewünschten Effekt. Damit komme ich nur in mein Benutzerverzeichnis.

 

[Pepe Rohny]

In jedem Fall ne gute Idee. Aber bringt leider auch nicht den gewünschten Effekt. Damit komme ich nur in mein Benutzerverzeichnis.

Mag sein - denn liegt das Programm aber auch in deinem Benutzerverzeichnis - oder?

Ich benutze

private static final String SYSTEM_PATH = new File(".").getAbsolutePath() + File.separator;

in meinen Programmen.

private static final String ICONS_PATH = SYSTEM_PATH + "icons" + File.separator;

ist dann eine Konstante für den Zugriff auf das "icons"-Verzeichnis.

So funktioniert das zumindest in meinen Programmen.

Pepe

 

[Michael...]

Ich benutze

private static final String SYSTEM_PATH = new File(".").getAbsolutePath() + File.separator;

in meinen Programmen.

das selbe liefert Dir doch

System.getProperty("user.dir")

?

@Mappenz: Dir geht es darum herauszufinden in welchem Verzeichnis die Klasse bzw. das Package liegt?

 

[Pepe Rohny]

das selbe liefert Dir doch

System.getProperty("user.dir")

?

stimmt

aber was ich eigentlich schreiben wollte: wenn der filechooser - wider Erwarten - das home-Verzeichnis darstellt, konnte er mit dem Pfad nichts anfangen. Daher die Frage an Mappenz: stimmt der Pfad denn?

Pepe

 

[mvitz]

new File(".")

liefert übrigens das Verzeichnis zurück, aus dem die Anwendung gestartet wurde (und das ist eben nicht zwangsweise

System.getProperty("user.dir")

(Auch wenn ein Doppelklick auf ein JAR unter Windows zu diesem Ergebnis führt!)

 

[Michael...]

new File(".")

liefert übrigens das Verzeichnis zurück, aus dem die Anwendung gestartet wurde

Bei mir liefert System.getProperties("user.dir") immer das Verzeichnis aus dem die Applikation gestartet wurde, unabhängig davon ob diese als jar per Doppelclick über Konsole/Batch aus einem beliebigen Verzeichnis gestartet wurde.

Allerdings habe ich diese Property erst ein einziges Mal seit dreizehn Jahren Java wirklich gebraucht und habe User's current working directory immer mit Verzeichnis aus dem die Applikation gestartet wurde gleich gesetzt.

 

[Pepe Rohny]

"." ist das aktuelle Verzeichnis.

mit

new File(".")

kann man das Verzeichnis bekommen, das das Wurzelverzeichnis der laufenden Anwendung ist. Mit dieser Information kann man dann weiter arbeiten

ich kenne jetzt nicht die Doku zu

System.getProperty("user.dir")

- vermute aber mal, das es nicht das home-Verzeichnis liefert (wie man vermuten könnte), sondern das aktuelle

wie das bei Windows ist weiss ich nicht, gehe aber davon aus, dass es genau so ist

Pepe

 

[Michael...]

ich kenne jetzt nicht die Doku zu

System.getProperties()
Benutzerverzeichnis ist

"user.home"

;-)

 

[mvitz]

Ok, habs gerade mal ausprobiert.

Es scheint in der Tat so zu sein, dass beide Ausgaben dasselbe Ergebnis liefern, ABER man kann sich nicht darauf verlassen, dass sie den Pfad ausgeben, in dem sich das JAR File befindet.

Beispiel

package de.mvitz.test.jf.workingdir;
import java.io.File;
import javax.swing.JOptionPane;
public final class Test {
    public static void main(String[] args) {
        final String message = new StringBuilder()
            .append("new File(.).getAbsolutePath() --> ").append(new File(".").getAbsolutePath()).append("\n")
            .append("System.getProperty(user.dir)  --> ").append(System.getProperty("user.dir"))
        .toString();
        JOptionPane.showMessageDialog(null, message);
    }
}

Diese Klasse liegt in einem JAR: D:\test.jar und im Manifest ist die Klasse als Main-Class definiert.
Ausführung per Doppelklick liefert für beides D:\test.jar (bzw. D:/test.jar aber das ist jetzt mal identisch).
Führt man jetzt das JAR aber über eine Konsole (z.B. cmd unter Windows) vom Verzeichnis C:\ aus, dann wird eben C:\ ausgegeben und nicht mehr D:\test.jar!

 

[Pepe Rohny]

Ok, habs gerade mal ausprobiert.

Es scheint in der Tat so zu sein, dass beide Ausgaben dasselbe Ergebnis liefern, ABER man kann sich nicht darauf verlassen, dass sie den Pfad ausgeben, in dem sich das JAR File befindet.

das jar

 

[mvitz]

Ja ok

 

[Michael...]

Führt man jetzt das JAR aber über eine Konsole (z.B. cmd unter Windows) vom Verzeichnis C:\ aus, dann wird eben C:\ ausgegeben und nicht mehr D:\test.jar!

So meinte ich das ja auch. Gilt aber für

"user.dir"

und

 new File("").getAbsolutePath()

? Es wird jeweils das Verzeichnis zurückgegeben aus dem das Programm ausgeführt/gestartet wurde.

Wenn es allerdings darum geht heraus zufinden, wo das Archive oder die Klassen liegen - deswegen meine Frage an den Thread Owner - hilft das nichts. Dazu könnte man den ClassLoader "verwenden" und die URL die

getResource("")

liefert auswerten.

 

[mvitz]

Ok, dann sind wir uns einig und ich hatte dich anscheinend nicht zu 100% verstanden.