Aufruf EXE auf Explorer

Hallo Zusammen,

mein Programm (mess.exe) speichert seine Mess/ Berechnungsergebnisse in mehrere *.lvm Datein ab (messung1.lvm, messung2.lvm ...).

Ziel ist es, durch einen Doppelklick im Windows Explorer auf eine solche *.lvm Datei das LabVIEW Programm mess.exe zu starten und die Messkurve in einem Graphen darzustellen.
Mit Hilfe des Parameters "Kommandozeilen" bekomme ich auch beim ersten Aufruf in meinem Programm die angeklickte Datei übergeben und kann sie dann öffnen und darstellen.

Wenn man allerdings bei bereits laufendem Programm "mess.exe" ein weiteres Mal eine *.lvm Datei im Explorer mit Doppelklick anwählt, wechselt Windows zwar zu meinem Programm "mess.exe", ich bekomme aber nirgends die Infos, welche *.lvm Datei man beim zweiten Mal angeklickt hat.

Kann mir da jemand weiterhelfen ?

Gruß jan

' schrieb:Wenn man allerdings bei bereits laufendem Programm "mess.exe" ein weiteres Mal eine *.lvm Datei im Explorer mit Doppelklick anwählt, wechselt Windows zwar zu meinem Programm "mess.exe", ich bekomme aber nirgends die Infos, welche *.lvm Datei man beim zweiten Mal angeklickt hat.

Nur so zum Testen mal den Dateinamen der .lvm in einem Stringcontrol darstellen...

Gruß SeBa

Hallo Seba,

da kann ich Dir nicht ganz folgen.

Ich lese die Kommandozeilenargumente permanet aus und schreibe sie in ein String Control.
Dort steht aber immer nur der Pfad der Datei des ersten Aufrufs drin.


jan

Wie du bemerkt hast ändert sich das Kommandozeilenargument nicht, obwohl du eigentlich ein Neues übergeben hast.

In der Hilfe fand ich folgenden Hinweis:

"Mit der Eigenschaft Applikation:Kommandozeilenargumente können die benutzerdefinierten Kommandozeilenargumente eingesehen werden, die beim Starten von LabVIEW übergeben werden."

Das scheint der Haken an der Sache zu sein...


Gruß SeBa

Wenn deine Applikation nicht irgendwelche Ressourcen exklusiv verwendet und nicht zwei Files miteinander verglichen werden etc. könntest du einfach ein zweite, dritte, nte Instanz öffnen. Ansonten halt per Drag&Drop.

Hi,
weiß nicht ob das weiterhilft, aber ich habe z.B. eine Auswahl von verschiedenen PDF-Dateien, die ich durch Zusammensetzen des Pfades als Argument mit in die Komandozeile übergebe:

LV8.6
  exeaufruf.vi (Größe: 6,87 KB / Downloads: 251)

Anzeige

Dazu müsste man in der LabVIEW Applikation ein DDE Interface implementieren und dieses für die EXE auch in der Registry registrieren, so wie Du es schon für die command line gemacht hast. Explorer versucht dann nämlich erst den DDE Server anzusprechen und wenn das nicht geht wird die command line aufgerufen und das File gemäss der Vorgabe in der Registry als Command Line Parameter mitgegeben. Nur wenn Deine Applikation schon läuft kann sie die Command Line nicht mehr sehen, deshalb die DDE Server Implementation.

Nun ist da aber ein grosses Problem.

1) Die DDE VIs sind zwar noch vorhanden aber aus der Palette entfernt. Man kann sie aber noch verwenden auch wenn die entsprechende DDE Library schon seit etwa LabVIEW 4 nicht mehr angefasst wurde.

2) Viel gravierender ist aber, dass der Explorer die DDE Kommandos mittels DDE Execute messages an die Applikation übermitteln will und genau das Empfangen von DDE Execute Messages ist in der LabVIEW DDE Library explicit ausgeschaltet. Warum weiss ich zwar nicht aber ich nehme mal an dass da eine unerwünschte Interaktion zwischen dem LabVIEW System und solchen DDE Execute Messages war und die einfachste Weise um das zu fixen halt bei der Initilialisierung von DDE explicit durch Windows filtern zu lassen. Eventuel hat es auch noch sicherheitstechnische Bedenklichkeiten.

Daher ist das eine totlaufende Sackgasse.

Die richtige Lösung, die von LAVA (lavag.org) kommt ist dann, um ein kleines Executable zu bauen das in der Registry für den Filetyp registriert wird. Dieses Executable wird immer über die Kommandline gestartet mit dem Filenamen als Parameter. Und dieses Executable macht nichts anderes als diesen Parameter zu lesen und ihn per VI Server oder Custom TCP/IP Protokoll an die eigentliche Applikation zu schicken und sich danach sofort zu beenden.

Hallo,
ja das stimmt. Es müsste etwas komplizierter sein, aber ich sehe eigentlich keine andere Lösung. Bei dem Sicherheitsaspekt gebe ich Dir vollkommen recht, dies wird sogar einer der Hauptgründe sein. Sofern das nicht sauber programmiert ist, wärem diese Messages ein Einfallstor für so nette Geschichten wie Pufferüberläufe und Co. Bei einer Applikation, die vermutlich in der Industrie eingesetzt wird ein zu hohes Risiko.
Gruß Thomas

Vielen Dank für die Antworten,

werde mich dann mal mit den Themen "VI Server" und "Custom TCP/IP Protokoll" auseinandersetzen.
Hatte damit bisher noch nichts zu tun.


Gruß jan