Beiträge von misterspeed

    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.

    Nunja, aber Schwachpunkt daran ist doch, dass du so auf jedem Gerät die Termine pflegen müsstest oder wie ist dein Plan für die Synchronisierung zwischen den Geräten? Deswegen bietet sich hier eben eine cloudbasierte Lösung an, z.B. über dein sicher bereits vorhandenes Smartphone.


    Klar mit Autoit hat das dann nix mehr zutun und hilft dir nicht wirklich bzgl. Erfahrung im Programmieren sammeln. Dennoch ist es eben die bessere Lösung. Wenn du mit Autoit vergleichbares erreichen willst wird das ein sehr aufwendiges Projekt, welches dich vermutlich überfordert.


    Aber zurück zum Standby Problem... schonmal getestet ob das Script auch dann den Betrieb einstellt, wenn du auf sleep verzichtest?


    Eine Möglichkeit wäre z.B. timerinit() / timerdiff() oder AdlibRegister() und das Makro @hour zu verwenden.

    Wenn das Script nur 2x am Tag eine Erinnerung anzeigen soll macht es kaum Sinn dieses permanent laufen zu lassen. Stattdessen würde ich einfach die Windows Aufgabenplanung nutzen und das Script zu den gewünschten Uhrzeiten aufrufen lassen. Vorteil is hier auch, dass die Windows Aufgabenplanung verpasste Programmstarts nachholen kann wenn der Rechner zur fraglichen Zeit gerade im Standby oder gar aus war. Dein Script müsste beim Start dann nur noch ermitteln ob es "morgens" oder "abends" ist und die entsprechende Meldung anzeigen, danach wird es beendet und Thema erledigt.


    Aber davon mal ab wurden für sowas Kalender Serientermine erfunden, sowohl auf dem Smartphone, als auch in Email Clients am PC.

    Da geb ich Musashi recht.


    Dennoch zu deinen Fragen:


    1. Um einen String zum Beispiel mit 0 aufzufüllen verwendet man die Funktion stringformat()

    Beispiel:

    AutoIt
    $sData = "2"
    $sDataFormated = StringFormat("%+03s",$sData)
    
    ConsoleWrite($sDataFormated & @CRLF)
    
    Exit


    2. Das Problem mit der Dateiendung könntest du komplett umgehen, wenn du statt irgendwelchen Edits und Usereingaben einfach einen FileOpenDialog() verwenden würdest. Hier kann der User dann einfach die gewünschte Datei auswählen.


    3. Falls du das weiterhin so tun möchtest verwende einfach if Bedingungen für beide Dateiformate

    Obiger Code ist natürlich grausam und kann auch massivst verkürzt werden, insbesondere wenn du noch mehr Dateiendungen abdecken willst macht das auf diese Art wenig Sinn.

    Sagen wir mal besser.


    1. Es bringt dir nichts ein Edit Feld direkt nach der Erstellung auszulesen, denn da ist es ja noch leer. Du musst es schon auslesen nachdem der Benutzer etwas reingeschrieben hat (z.B. wenn er den "öffnen" Button drückt).

    2. Die Variable $idEditProjekt ist ebenfalls leer und ungenutzt, deine Zeilen zum Ändern der Schrift bringen also rein garnichts

    1. Du verwendest die Variable $rnr garnicht, sondern deklarierst sie nur, vermutlich willst du den Inhalt des Editfeldes $flst

    2. In den Variablen $gem, $fl und $flst sind nicht die Werte gespeichert, welche du in das Edit einträgst, sondern die ControlID, also eine eindeutige ID mit der du das GUI Control auslesen, bearbeiten oder auch verschieben kannst.

    3. Um den Inhalt eines Controls auszulesen verwendet man die Funktion guictrlread()

    Nun lass mich mal eben zusammenfassen welche Dinge du hast:


    1. Du hast einen funktionierenden Keylogger und kannst für jeden Tastendruck den vKey ermitteln

    2. Du hast eine Funktion um das gesetzte Keyboard Layout auszulesen und vermutlich wäre es auch simpel das Keyboard Layout auf beliebige andere Sprachen in einer Testumgebung festzulegen

    3. Du kannst prinzipiell die geloggten vKeys in ein eigenes Textfenster umleiten oder ggf. auch automatisiert alle 255 vKeys senden um diese mit dem gesuchten Zeichen "(" abzugleichen


    Daraus ergibt sich, dass du eine vKeyMap und Zuordnung zum Keyboardlayout automatisiert für hunderte Sprachen vorab erstellen und für spätere Wiederverwendung in deinem oder weiteren Scripten speichern könntest.

    Der einmalige Aufwand und Dauer solch eine Tabelle zu generieren dürfte sich in Grenzen halten und wäre dafür dann auch zuverlässig in der Zukunft einsetzbar.

    Ich frag mich immernoch aus welchem Grund man systemweit mitschneiden sollte wann das Zeichen "(" gedrückt wurde. Was ist an diesem Zeichen so besonders und wozu brauchst du diese Erkennung?


    Ich verstehe, wenn man diese Erkennung in einem eigenen Textfenster benötigt, um z.B. eine Autovervollständigung in einer IDE zu ermöglichen. Aber das begrenzt sich dann ja auf (d)eine Anwendung und erfordert kein systemweites Keylogging bzw. allgemein kein Keylogging, da du einfach den Inhalt des Textfeldes überwachen und abgleichen könntest.


    Versteh das nicht falsch, ich bin einfach neugierig wozu man genau sowas braucht.

    Naja da dort Linux läuft und das "terminal" vermutlich nix anderes ist als eine webbasierte SSH Verbindung würde ich die Webautomatisierung komplett weglassen und direkt per SSH zugreifen. Putty sollte entsprechend automatisierbar sein um sowohl login, als auch reboot zu bewerkstelligen, ganz ohne fehleranfällige Tastatur Emulation oder Webseitenautomatisierung.


    EDIT:

    Plink aus dem Putty Paket sollte das können was du brauchst

    https://www.thegeekstuff.com/2017/05/putty-plink-examples/ (siehe Punkt 3)

    https://the.earth.li/~sgtatham….60/htmldoc/Chapter7.html (siehe Parameter zur PW Übergabe)