Relativer Pfad in INI-Datei

wunderschönen Tag allerseits,

In einem Labview-Projekt, dessen Entwicklung ich übernommen habe, ist der Pfad zu einer mehreren .llb-Dateien in einer INI-Datei als absolut-Pfad gespeichert. Je nach Auswahl zur Laufzeit soll eine der LLBs dynamisch per "Call by reference" eingebunden werden. Der Speicherort des kompilierten Programms ändert sich aber. Das führt dazu, dass die LLBs da nicht mehr gefunden werden.

Die INI-Datei liegt im Verzeichnis \Project\INI-files und die .llb im Verzeichnis \Project\Libs. Das ReadINI.vi, das die INI-Datei ausliest, liegt selbst in einer LLB mit dem Pfad \Project\Libs\fileIO.llb . Der Projekt-Daten-Pfad ist hier \Project\Data .

In der INI-Datei habe ich anstelle des absoluten Pfades folgendes eingetragen.:

Code:

[DLL_PATH]
G_PATH="..\Libs"

Leider bleibt der ausgelesene Pfad hier ein leerer String.
Wie muss ich den Eintrag ändern, damit die Pfad-Angabe, relativ zum INI-Datei-auslesenden VI gelesen werden kann?
Interessant wäre hierfür neben der Windows- auch die UNIX-Notation
Vielen dank für hilfreiche Antworten.

viele Grüße
Stefan

Anzeige

Hallo Stefan,

eher ein "Workaround" als ein wirklicher Tipp:
Speicher den Pfad doch als String in der INI statt direkt als Pfad. Dann hast du nämlich selbst alle Optionen, den String entsprechend aufzubereiten (sowohl beim Speichern in der INI als auch beim Zurücklesen) und bist nicht auf LabVIEWs Versuche, den Pfad zu entschlüsseln, angewiesen.

Ob eine eigene Routine dies besser macht, hängt dann nur von deinen Künsten ab!

Du solltest auch fleißig Gebrauch machen von den Funktionen "Applikation Directory" und "Get SystemDirectory". Dann musst Du dich überhaupt nicht mit absoluten Pfaden herumschlagen.
Wenn das Programm für alle Benutzer installiert ist, dann gehören Daten wie die INI-Date z.B in den Ordner "öffentliche Anwendunsdaten".Die Daten mit in den Windows-Programmordner zu legen, geht seit Win7 gar nicht mehr.
   

vielen Dank für die Antworten.
Eigenartig finde ich ich, dass mit application-directory nicht der Pfad des Projektes selbst sondern nur der übergordnete Pfad ermittelt wird. Sonst wäre das genau die Funktion, die ich brauche.

viele Grüße
Stefan

Versteh ich nicht.
Wenn ich ein Programm abc.vi im Verzeichnis c:\def\ laufen habe, und rufe dort die Funktion "application directory" auf, dann ist das Ergebnis:
c:\def
Das ist das Verzeichnis, in dem sich das VI befindet. Diesen Ordner als "übergeordneten Pfad" zu bezeichen entspricht nicht gerade der gängigen Teminologie. Und was hast du daran auszusetzen bzw. was würdest Du dir denn wünschen, was "application directory" statt dessen anzeigen sollte?

(28.02.2013 09:22 )Lucki schrieb:  Versteh ich nicht.
Wenn ich ein Programm abc.vi im Verzeichnis c:\def\ laufen habe, und rufe dort die Funktion "application directory" auf, dann ist das Ergebnis:
c:\def
Das ist das Verzeichnis, in dem sich das VI befindet. Diesen Ordner als "übergeordneten Pfad" zu bezeichen entspricht nicht gerade der gängigen Teminologie. Und was hast du daran auszusetzten bzw. was würdest Du dir denn wünschen, was "application directory" statt dessen anzeigen sollte?

Ich habe mehrere Labview-Projekt die ins Verzeichnis "D:\Projekte\Labview\builds" kompiliert werden und darunter jeweils einen eigenen Ordner bekommen. Anstatt "D:\Projekte\Labview\builds\Projekt1", wie ich es benötigen würde, gibt mir "get application directory" aber nur die Ausgabe "D:\Projekte\Labview\builds" aus bzw. auf dem Zielrechner nur das Verzeichnis, in das ich mein Programmordner hineinkopiert habe ohne den Programmordner selbst.
Das von Dir beschrieben Ergebnis erhalte ich stattdessen über die Funktion "Current VI's Path".
Auf einen Installer hab ich der Bequemlichkeit halber verzichtet, da es mir das beim ständigen Testen neuer Versionen auf dem Zielrechner zu umständlich ist jedesmal eine Instalationsroutine laufen zu lassen.

viele Grüße
Stefan

Anzeige