Problem mit FileOpenDialog() und anschliessendem Run()

    Salü miteinander

    Das Problem klingt komisch, und ist es auch:

    Nachdem ich FileOpenDialog(,,,) benutzt habe, funktioniert die Funktion Run([programm]), _RunDOS([programm] etc. nicht mehr. Das Programm wird einfach nicht aufgerufen.

    Ich wähle NICHT mit FileOpenDialog() das auszuführende Programm aus. Ich wähle ein anderes. Dieses wird - sobald ich "FileOpenDialog()" weglasse, aufgerufen und durchgeführt.

    [autoit]


    $ScriptFileOpener=FileOpenDialog("Bitte File wählen",@scriptdir&"\Scripts","All Files (*.*)",1)
    Run(@scriptdir&"\batfile.bat")

    [/autoit]

    Ach ja... der Batfile, dessen Inhalt ich in einer Funktion erzeuge, greift schlussendlich auf psexec zu... und es funktioniert tatsächlich, wenn ich FileOpenDialog() weglasse... *kopfkratz*

    Ich greif mir an die Rübe... kennt das jemand? Weiss jemand, wie das umgangen werden kann? Oder ist das nur auf meiner verk**** Maschine so? Habe n Windows 7

    Wär froh um etwas Input....

    Einmal editiert, zuletzt von Landfloh (7. Februar 2014 um 16:04)

    Also nur damit niemand denkt, ich würde was illegales mit psexec machen:

    Ich möchte Scripts auf unseren Kassensystemen ausführen können. Statt alle Scripts hard-zu-coden und mit Button zu versehen, möchte ich via FileOpenDialog die Möglichkeit geben, irgend ein Script auswählen zu können.... macht ja irgendwie Sinn, oder? *g*

    Und um PSexec benutzen zu können, brauch ich die erforderlichen Rechte auf den Kassen, und die hab ich ja... ist also alles sehr legal... hihi...

    Also bitte, wenn jemand von Euch Cracks da was dazu weiss... her damit... bitte... wär mir ne riesen Hilfe... ich hab schon in den Tisch gebissen und ein Wut-Bier hinter mir, und das mitten am Nachmittag... tss..

    FileOpenDialog ändert das WorkingDirectory auf den Pfad der ausgewählten Datei (Siehe >>AutoIt-Hilfe<<)
    Das ist für den Aufruf der Batch noch kein Problem, da du ja den Pfad explizit mit @Scriptdir festlegst. Allerdings wirst du das nicht in der Batch machen. Die Batch arbeitet nämlich nun im Arbeitsverzeichnis der ausgewählten Datei.
    Dein Run ist also nicht dein Problem - es ist die Batch.

    Am einfachsten wäre wohl die Funktion FileChangeDir() zu nutzen.

    Also in der BAT steht folgendes:


    psexec -h \\xxx.xxx.xxx.xxx -u USER -p PASSWORD -i "\\xxx.xxx.xxx.xxx \c$\TimeServer.bat" -d

    Ich kopiere in einer Funktion erst einen File auf das Zielsystem. Dann rufe ich die Batch auf, und führe diese kopierte Datei aus... die Batch wird jeweils gemäss angewähltem Zielsystem und File erstellt. D.h. damit hats nix zu tun. Ich habe dann angefangen, mit einem fixfertigen Batch zu arbeiten, der funktioniert wenn man ihn selbst anklickt. Er funktioniert auch, wenn ich ihn via "Run()" anwähle. Er funktioniert NICHT wenn ich vorher die Funktion FileOpenDialog() verwende, sogar dann nicht, wenn ich mit der zurückgegebenen Variable (=Kompletter Pfad zum gewählten Script) gar nichts tue. (!!)

    Das ist doch mehr als schräg, oder?

    Die Batch ruft die Datei psexec auf. Allerdings sucht es die Datei nicht im Skriptverzeichnis sondern in dem Verzeichnis in welchem die Datei liegt, welche du mit FileOpenDialog aufgerufen hast.
    Gibt es die Datei psexec in diesem Pfad?

    Zitat von AspirinJunkie

    Die Batch ruft die Datei psexec auf. Allerdings sucht es die Datei nicht im Skriptverzeichnis sondern in dem Verzeichnis in welchem die Datei liegt, welche du mit FileOpenDialog aufgerufen hast.
    Gibt es die Datei psexec in diesem Pfad?


    Also ich hab zwei Verzeichnisse: IPchecker und IPChecker\Scripts

    im IPchecker ist die BAT und das PSEXEC.

    Die anzuwählenden Scripts sind im Unterordner "Scripts". Da ich ja die BAT explizit im @scriptdir suche (und finde), sollte die gewählte Datei ja überhaupt keinen Einfluss auf den BAT-Suchpfad haben.

    Ich habe spasseshalber aber die Bat und das PSexec mal in den Ordner Scripts kopiert. Und siehe da: es funktioniert. Ich verstehe es nicht, und halte das ganze für nen Bug. Aber ich hab ne Umgehungslösung gefunden. Vielen Dank für die Hilfe.

    OOOH... jetzt verstehe ich Dich erst...

    FileOpenDialog verändert das WorkingDirectory. Und die BAT arbeitet mit dem WorkingDirectory... Du bist n Genie.. lol... und ich kotzdämlich. Danke vielmals.. hihi.

    Ich wünsch Dir ein schönes Wochenende.

    Zitat von AspirinJunkie

    Am einfachsten wäre wohl die Funktion FileChangeDir() zu nutzen.


    Sollte nicht notwendig sein, denn der Funktion run() kann man auch explizit das workingdir mitgeben. Es sollte also reichen den run Aufruf so zu wählen:

    [autoit]


    Run(@scriptdir&"\batfile.bat",@scriptdir)

    [/autoit]

    Ja das ist eine Möglichkeit.
    Mein Gedanke warum ich von "einfacher" sprach war, dass mit FileChangeDir nur einmal an einer zentralen Stelle das Arbeitsverzeichnis festgelegt wird.

    Wenn man mit dem WorkingDir-Parameter von Run arbeitet muss man die zu startende Datei mit @ScriptDir schreiben und beim WorkingDir ebenfalls.
    Und das jedes mal wenn man Run verwendet.
    Wenn man stattdessen einmal FileChangeDir verwendet kann ab sofort jeder Run-Aufruf ganz einfach so aussehen:

    [autoit]

    Run("batfile.bat")

    [/autoit]

    Ich persönlich finde es eigentlich eher bisschen unglücklich, dass mit FileOpenDialog automatisch das WorkingDir angepasst wird.

    Guten Morgen zusammen,

    habe auch wie ein Depp an diesem Problem gehangen (Neuling) bis ich herausgefunden habe wieso nach dem FileOpenDialog
    Funktionen nicht mehr funktionieren die zuvor problemlos durchgelaufen sind.
    Erst einmal DANKE für die elegante Problemlösung!

    Also verstehe ich es richtig (kann gerade nichts prüfen) das wenn ich nach dem FileOpenDialog und dem verarbeiten der daraus
    resultierenden Informationen die ein FileChangeDir auf die $ScriptDir anwenden muss damit mein Script alles wieder findet ohne
    das ich den kompletten Pfad ausschreiben muss, richtig?


    Danke und schönen Gruß

    Kommt darauf an.

    Im Normalfall (man startet das AutoIt-Skript direkt aus dem Explorer) ist @ScriptDir=@WorkingDir.
    Manchmal ist es aber auch sinnvoll das Skript mit einem anderen WorkingDir zu starten.
    Nämlich z.b. Wenn das Skript im Programmeordner liegt und du es z.B. aus der Kommandozeile in einem anderen Pfad aufrufst wo es verschiedene Dinge tun soll.

    In diesem Fall wäre es fatal wenn du manuell das WorkingDir auf @ScriptDir zurückstellst, da dann das Feature direkt ohne umständliche Pfadangaben in anderen Ordnern zu arbeiten wegfällt.

    Wenn das Skript immer mit @ScriptDir=@WorkingDir laufen soll, kannst du FileChangeDir hinter FileOpenDialog entsprechend aufrufen.
    Jedes weitere mal wenn du FileOpenDialog oder FileSaveDialog aufrufst müsstest du das aber wiederholen.
    Die Alternative dazu hatte misterspeed erläutert: Mit vollständigen Pfadangaben für Dateien und Arbeitsverzeichnisse arbeiten.

    Danke für die schnelle Rückmeldung.

    Ich brauche das Script wenn es fertig ist für die Arbeit, da soll es ein anderes Programm "bedienen", soll heißen
    die zu bearbeitende Datei wird fortan über den OpenFileDialog des Scripts (was dann als EXE compiliert vorliegen muss)
    an die Dateiauswahl des "Hauptprogramms" übergeben.
    Dann sollen mittels _ImageSearch diverse button geklickt, eingaben getätigt werden usw usw... bis schlussendlich
    alles abgespeichert und geschlossen wird.

    Das _ImageSearch braucht eine DLL und entsprechend die Bildchen, die nicht gefunden wurde als ich das Problem mit dem FileOpenDialog noch hatte, und an sich soll das Script funktionieren solange es seine erforderlichen Dateien einem definierten Unterordner der @ScriptDir hat.