Beiträge von misterspeed

    Die Schwierigkeit ist eher den Standardbrowser (in dem Fall deine eigene Autoit.exe) für alle Benutzer des Systems als Standard zu setzen. Dazu gab es vor einigen Monaten hier mal einen Thread.


    Wenn dir das zuverlässig gelingt ist der Rest keine besondere Herausforderung. Der Link wird immer als Parameter an den definierten Standardbrowser übergeben und ab da kannst du dann tun was immer du möchtest. Eine weitere Schwierigkeit wäre evtl. noch den gewünschten "normalen" Browser des Users zu erkennen und dann entsprechend den Aufruf dorthin umzuleiten wenn der Link deinen Kriterien entspricht. Das machst du am besten bevor du den Standardbrowser auf deine Autoit.exe umstellst und speicherst die "original" Einstellung des Users in einer ini Datei.


    EDIT:

    Hier das Thema bzgl. Standard App Festlegung unter W10 -> RE: Dateitypen für eigenes Programm registrieren

    So auch mit alle anderen (ausführbaren) Erweiterungen, die in PATHEXT enthalten sind.

    Danke, wusste ich in der Tat nicht. Sicherer ist es jedenfalls grundsätzlich vollständige Pfadangaben für Dateien jeder Art zu verwenden und ggf. auch vorab auf deren Existenz und bei Bedarf via Hash auf Authentizität zu prüfen.

    Sind dir die Dateinamen vollständig bekannt, sobald du die Projektnummer hast oder gibt es je nach Projekt weitere Variable Teile des Namens? Im ersteren fall könntest du auf eine Suche im Dateisystem komplett verzichten und müsstest lediglich auf die Existenz der 4 Dateien prüfen.

    Mal von den vielen angebrachten Tipps abgesehen hat scheinbar noch niemand den echten Fehler entdeckt:


    AutoIt
                ;PCO-View
                Run("X:\bin\.pcoview")
                WinWaitActive("PCO View Login")
                send($user)
                send("{TAB}")
                Send($pwd)
                Sleep(1000)
                Send("{ENTER}")
                Sleep(1500)
                WinWaitActive("bwms-app")


    Dein run(...) Aufruf von PCO-View ist schlichtweg falsch (Dateiendung fehlt). Daher wird das Programm nicht gestartet und dein Script bleibt sehr wahrscheinlich beim darauffolgenden WinWaitActive(..) hängen.

    Angenommen es würde funktionieren wie du es willst... ist Adlibregister dann überhaupt eine sinnvolle Wahl? Die in Adlibregister registrierte Funktion zur Verarbeitung könnte deine Funktion zum neu Befüllen deines Arrays unterbrechen. Angenommen das passiert bei 50% des Füllvorgangs, dann verarbeitest du zur Hälfte "alte" Daten und zur Hälfte "neue" Daten. Wenn das ein Problem wäre kommt das so ohnehin nicht in Frage.

    Und wenn du Scite ebenfalls mit Adminrechten startest?


    Vermutlich ein Rechteproblem, bei dem weniger priviligierte Prozesse (scite) nicht mit Prozessen höherer Berechtigung Kommunizieren können. Aus diesem Grund funktioniert z.B. auch kein Drag and Drop von "normalen Benutzer Fenstern" in "Admin Fenster".

    Nunja, sofern Oscar recht hat und das Event immer genau zweimal triggert kannst du dir auch einfach mit einer Zählervariable behelfen.


    Ohne das Programm zu kennen oder mir das angeschaut zu haben... hast du mal geprüft ob die Software einen Windows Dienst eingerichtet hat? Die Tatsache, dass unsauberes Beenden erkannt wird deutet jedenfalls darauf hin, dass es nebend er GUI bzw. Trayicon noch einen überwachenden Hauptprozess gibt. Falls es sich dabei um einen Windows Dienst handelt genügt es evtl diesen zu beenden.


    Via DOS Befehl ginge das z.B. so:

    Code
    net stop servicename

    Entweder per run(...) ausführen oder ggf. eine passende Funktion der Win API direkt via Autoit nutzen.

    Benötigt die Software evtl. Adminrechte?

    AutoIt
    #RequireAdmin


    Mal versucht beim Run Aufruf das "Workingdir" festzulegen?

    AutoIt
    Run ( "program" [, "workingdir" [, show_flag[, opt_flag ]]] )


    Ahja und Falls es eine 32bit Anwendung ist sollte dein Autoitscript ebenfalls 32bit sein bzw. 64bit bei einer 64bit Anwendung um Probleme mit Windows FS Redirection zu vermeiden.

    AutoIt
    #AutoIt3Wrapper_usex64=Y
    ; oder
    #AutoIt3Wrapper_usex64=N

    Wozu umständlich, wenn es auch einfach und direkt geht?


    https://www.autoitscript.com/a…nAPI_GetParentProcess.htm


    Damit bekommst du die PID des Parent Prozesses eines beliebigen Unterprozesses. Der Parentprozess muss nicht zwangsläufig ein Fenster und erst recht keinen Fenstertitel haben. Mag vielleicht bei Chrome und FF derzeit zutreffen, aber dass das prinzipiell so wäre und auch so bleibt würde ich mal lieber nicht annehmen.


    32vroni

    Laufen die "chrome.exe" Prozesse alle im gleichen Benutzerkontext, oder handelt es sich evtl. um Prozesse eines anderen Benutzers / Dienstes? Ist letzteres der Fall fehlen deinem Autoit Prozess die Berechtigungen um die Prozesse zu beenden. Hier helfen in der Regel Adminrechte für das Script. In sehr seltenen Fällen sind sogar Systemrechte notwendig (z.B. möglich wenn es sich um Unterprozesse eines Updatedienstes handelt).

    Mögliche Ursachen:


    - Windows FS Redirection: Dein Autoitscript ist 32bit und dadurch werden die Windows System Pfade auf die jeweiligen 32bit Pfade umgelenkt. In deinem Fall dann vermutlich "C:\Windows\SysWOW64" statt "C:\Windows\System32". Dort gibt es dann auch tatsächlich keine "wuauclt.exe"


    - Arbeitsverzeichnis falsch: Beim Run Aufruf kannst du explizit ein Arbeitsverzeichnis mitgeben. Sofern dein Script nicht auf C:\ ausgeführt wird kann auch das gelegentlich dazu führen, dass Standard Windows Befehle nicht richtig umgesetzt werden.


    Ich tippe auf Variante 1. Die einfachste Lösung wäre dein Script als 64bit Script zu kompilieren. Gibt dafür aber auch andere Lösungen, die die Windows FS Redirection temporär für dein Script abschalten oder du verwendest den "sysnative" Pfad.


    Details siehe hier:


    Vorhandene! bcdedit.exe kann NiCHT vom Script ausgeführt werden weil es diese exe nicht findet

    http://www.samlogic.net/articl…folder-64-bit-windows.htm

    https://www.autoitscript.com/a…bleWow64FsRedirection.htm

    Vielleicht solltest du die Randbedingungen, den IST-Zustand und SOLL-Zustand doch mal genauer erklären. Ich bin mir ziemlich sicher, dass es auch möglich ist vor Nutzung von Teamviewer sämtliche gespeicherten Daten zu löschen und dir somit deinen Idealzustand herzustellen, bei dem du selbst deine Daten via Autoit eintragen kannst (das funktioniert ja anscheinend).


    Zu den grundlegenden Infos die man benötigt um dir zu helfen gehört z.B.:

    - Teamviewer Version

    - Teamviewer Lizenzierung (Free oder Abo?)

    - Wer nutzt dein Script bzw. den Rechner auf dem das Script ausgeführt wird

    - Bist du Alleinnutzer oder hast du eingeschränkte Möglichkeiten den Rechner zu verwalten?

    - Auf welches System oder auf welche Systeme wird zugegriffen?

    - Sind dir die Zugangsdaten (ID und PW) immer für alle Systeme bekannt?

    - usw.

    Normalerweise bietet solche Software selbst eine Option um nach Abschluß der Aufgabe Aktionen wie "Programm beenden" oder "Computer herunterfahren" durchzuführen. Eine feste Uhrzeit ist jedenfalls wenig sinnvoll, da wie bereits erwähnt wurde für Windows oder Autoit nicht bekannt ist ob zu diesem Zeitpunkt bereits alle Aufgaben abgeschlossen wurden. Würde dir daher die Dokumentation deiner Rendering Anwendung empfehlen, denn das ist mit Sicherheit zuverlässiger als über externe Software herauszufinden ob alles erledigt ist.

    Bzgl. Schritt 2 (Ausdruck der PDF):


    Dafür brauchst du normalerweise auch keine GUI Automatisierung eines PDF Viewers. Siehe z.B. hier https://www.autoitscript.com/f…61202-silently-print-pdf/

    Allerdings landet der Shellexecute Aufruf standardmässig beim Default Drucker des Benutzers. Daher wird im obigen Thread Sumatra erwähnt (portabler PDF Viewer, der scheinbar mit commandline Befehlen auch auf beliebigen anderen Druckern drucken kann).


    Alternativ könnte man mit Autoit aber sicher auch den aktuellen Standard Drucker ermitteln, auf einen anderen wechseln und danach wieder zurückstellen. ;)

    Und welche Webapplikation ist das? Handelt es sich um die Webseite eines Logistikunternehmens wie DHL, UPS, TNT usw. oder ist das ein anderes Produkt?


    Hintergrund der Frage:

    Sicher kann man Webseiten automatisieren indem man Benutzeraktionen wie Mausklicks simuliert. Sehr viel einfacher, zuverlässiger und performanter geht das aber, wenn die Webseite eine API für genau solche Zwecke bereitstellt. Dann reichen im Idealfall wenige Zeilen Text direkt an den Webserver ohne lahmen Browser dazwischen, damit er dir das gewünschte Dokument bereitstellt.

    Zwar etwas OffTopic, aber wer schonmal den Acrobat Reader genutzt hat hat sicher schon den sehr ungewöhnlichen Workaround von Adobe gesehen um den Acrobat Reader zum Standardprogramm für PDF Dateien zu machen. Hab mich schon sehr lange gefragt wieso eine große Firma wie Adobe auf solche Tricks zurückgreifen muss und die notwendigen Registry Schlüssel nicht einfach selbst setzt.


    Adobe umgeht das Problem durch Anzeigen des Dateieigenschaftenn Dialogs einer mitgelieferten PDF Datei und fordert den User dann zum anklicken des "Ändern" Buttons bei "Öffnen mit" über eine Overlay GUI auf. Scheinbar ist das die einzigste zuverlässige Methode für PDF Dateien, andernfalls hätte man das sicher nicht so primitiv bei Adobe gelöst.


    Aber auch das Setzen des Standard Browsers scheint nicht ganz so simpel zu sein. Firefox öffnet dafür einfach den Dialog von Windows in dem die Standard Apps festgelegt werden können.


    Microsoft hat hier definitiv Hürden eingebaut, die es so in früheren Windows Versionen nicht gab.