Beiträge von HansJ54

    Hallo zusammen,

    nach einer Zeit der Abstinenz sitze ich mal wieder vor dem Rechner.

    Ich suche eine Möglichkeit, Klicks auf Links in Mails (Outlook) abzufangen und zu verarbeiten. Also eine Routine, die ich anstelle der vordefinierten Windows-Routine registriere und die mir die Möglichkeit gibt, vor Aufruf des Browsers die URL zu überprüfen und dann, wenn ok, den Browser mit der URL aufzurufen.

    Mir fehlt jetzt eine Idee zum "Anfang" der Sache, also das Übernehmen des Aufrufs. Die Überprüfung und den späteren Browseraufruf habe ich im Griff.

    Hat jemand eine Idee?

    Verstanden habe ich die Sache allerdings trotzdem nicht:

    DLLCall("user32.dll","int","AddClipboardFormatListener","HWND",$gui)

    hängt das Fenster $gui in die Clipboard-Event-Liste

    GUIRegisterMsg($WM_CLIPUPDATE,"OnClipBoardChange")

    $WM_CLIPUPDATE=0x031D <-- ist das eine Windows-ID für das Event im Clipboard hat sich etwas geändert?

    Wenn ja:

    Gibt es irgendwo eine Liste der Codes für alle möglichen Windows-Events so wie CLIPUPDATE=0x031D? Habe gesucht, aber nichts gefunden.

    Habe die Lösung gefunden: das GUI ist hier im Beispiel nur ein Dummy. Jede Veränderung im Clipboard führt zu einer Anzeige der letzten Änderung.

    Ich habe ein kurzes Script aus 2012 gefunden, aber verstehe nicht die Funktionsweise. Irgendwie hängt das an einer GUI. Ich brauche nur den String ClipGet() ohne das Fenster in meinem Programm.

    Du hast Recht, durch das "Local" werden die Variablen ja im Prinzip schon gestackt. Und durch das "Local" kann man beide Werte platzsparend in nur eine Zeile schreiben. Das ging bei mir nicht, weil ich die Variablen außerhalb als "Global" deklariert hatte.


    Das "called from" hatte ich schon mal mit einer eigenen Function() implementiert, brauche ich aber zum Debuggen eigentlich nicht. Mit "Local" statt "Global" komme ich super hin. Danke!

    Du hast Recht. Ohne das "After" könnte man nach Beenden z.B. von verschachtelten Funktionen nicht wissen, wohin und ab wo man zurückgekommen ist. Wobei natürlich dann die Zeilennummern helfen könnten, wenn man nicht gerade zwischen 2 Includes hin- und her gesprungen ist.

    Allerdings auch schwierig, wenn es innerhalb einer Funktion an mehreren Stellen Returns gibt. Dazu müsste man die Werte dann in einen Stack schreiben. Mit jedem Function-Call was obendrauf und jedem Return wieder weg.

    Das wäre dann wohl ein "Feature Request" für AutoIt (mit wenig Chancen zur Verwirklichung) ;)

    Schade, aber danke - dann muss ich nicht weiter suchen.

    Als Workaround ist natürlich möglich, dass ich in jeder Function() stattdessen $sFuncName="xxx" und $sInclude="yyy" vorne deklariere.

    Um die Funktionen nicht zu sehr aufzublähen, ist es irgendwie möglich, 2 Befehle in eine Zeile zuschreiben?

    Oder anderer Workaround: Func _Umgebung($sFuncName, $sInclude) und dann in jeder Function die Function als erstes aufrufen.

    Oder noch eine Idee: bei irgendwelchen alten Programmiersprachen (Fortran, Cobol?), die ich mal vor vielen Jahren gelernt habe, konnte man irgendwelche Variablen für die Kompilierung definieren, die als erstes in einem Precompile einfach ersetzt wurden. Also oben $$Include="xxx" und unten im Programm wurden dann alle $$Include vor dem Compile durch "xxx" ersetzt.

    He He - das ist nicht auf meinem Mist gewachsen. :rofl:

    Eure Namen sind zum Verwechseln ähnlich - zumindest wenn es so warm ist wie jetzt :rofl:


    Gleich noch eine doofe Frage: der String, den ich mit StringSplit in das Array stecke, hat am Ende einmal einen leeren Eintrag und dann noch einen mit 1 Byte. Jetzt brauche ich mal eine Idee, wie ich den String vor dem Zerlegen in Hex Byte für Byte anzeigen kann um zu sehen, was da hinten dran hängt. Auf Anhieb nichts dazu gefunden, wie das geht.

    Quatsch, das ist so, als ob du Äpfel mit Birnen vergleichst... in Post #9 verwendest du in dem Run() den Befehl Find, in Post #14 machst du es ganz anders - ohne Find.

    Könnte man so verstehen, aber ich meinte "das Problem mit dem Suchstring" - im neuen Script also ohne Problem da ohne Find und funktioniert ja perfekt;)

    Dasselbe wie bei dir: Hiermit werden alle Prozesse, die dem Suchmuster entsprechen, terminiert (gekillt).

    Kannte ich auch noch nicht, wieder was gelernt - merke ich mir für andere Einsätze, spart einiges an Code. Aber im Moment will ich den User noch fragen, ob er einverstanden ist mit dem Beenden seiner Fenster oder ob er sie lieber selbst schließt und das Programm wartet so lange.

    Falls es interessiert: wir nutzen den Webdriver und die UDF dazu von DANp und haben es noch nicht geschafft, eine erneute Verbindung mit einem noch laufenden Webdriver aufzunehmen, wenn der User das Programm vorher beendet hat. Und da wir immer genau dasselbe Profil benötigen, hängt die Geschichte beim Neustart, da ein neuer Chrome nicht auf das noch in Nutzung befindliche Profil zugreifen kann und stattdessen ein neues produziert. Bleibt nur Terminieren von altem Webdriver und allen Chromes oder Edges, die ihr Profil blockieren. Falls jemand eine brauchbare Beschreibung findet, wie man die Verbindung zu einem laufenden Webdriver wieder neu aufnehmen kann, großen Dank!


    Zitat von HansJ54 Und wmic path und wmic process sind gleich? Hä?

    Wie schon erwähnt, ich kannte den Befehl wmic bis vorgestern überhaupt noch nicht, erst durch Deine Info. Und ich habe außer auf der Seite von Apfelböck nirgendwo eine brauchbare Beschreibung gefunden. Daher der Gedanke "Process" beschäftigt sich mit den Prozessen (das war mein Ziel) und "Path" war für mich gedanklich ganz etwas anderes. Funktioniert aber scheinbar für meinen Zweck genau so gut.


    Auf jeden Fall danke für Eure Hilfe!

    Die schnellste Lösung ist meist PowerShell, so auch hier. Und die Ausgabe ist komplett.

    Danke an beide! Jetzt habe ich endlich ein Beispiel, wie ich PowerShell in AutoIt nutzen kann, aber mit meinem Script hole ich mir schon die gesuchten PIDs in ein Array mit dem ich die betreffenden Prozesse beenden kann. Ich suche tatsächlich nicht chrome an sich, sondern die chromes, die ein bestimmtes Profil nutzen ($sSearch = "chrome_wd_profil"). Und wmic ist auch schnell (von wmic hatte ich noch nie etwas gehört) ;)

    Aber jetzt brauche ich noch einen Tipp, ob es eine AutoIt-Funktion gibt, die die letzten Elemente oder alle Elemente, die leer sind, aus einer Tabelle löscht oder ob man es nur in der Art wie mein _ArrayClear() machen kann.

    Dank Deinem Tipp mit wmic habe ich eine eine Lösung gefunden, die das nicht mehr vollständig funktionierende _WinApi_GetProcessCommandline() umgeht. Funktioniert nach ersten Tests auch ohne Admin-Rechte und kann sicher für alle möglichen Zwecke umgestaltet werden.


    Ausgabe:


    Um die aus unerfindlichen Gründen entstehenden leeren Einträge am Ende des Arrays zu entfernen, habe ich _ArrayClear() geschrieben. Da gibt es aber sicher eine bessere direkte Funktion in AutoIt? Wäre nett, wenn Du mein Script ein wenig optimieren könntest.

    Das sieht schon etwas anders aus...

    Das funktioniert tatsächlich, aber dauert und das Admin-Fenster ist nicht so gut bei den einfachen Usern. Wenn ich mich auf Chrome beschränke, geht es schneller aber das Admin-Problem bleibt.


    Code
            For $i = 1 To UBound($aList) -1
                If $aList[$i][0] = "chrome.exe" Then
                    $aList[$i][2] = _Proc($aList[$i][0])
                    If StringInStr($aList[$i][2],"Profile") Then ConsoleWrite('PID: ' & $aList[$i][1] & @TAB & $aList[$i][2] & @CRLF)
                EndIf
            Next

    Hast Du eine Idee, was bei meinem Run() falsch ist?

    Nö, falscher Fehler. Mit $sOutput = StdoutRead($iPID) hat es nicht funktioniert und dann kam ein Test, den ich nicht vollständig zurückgenommen habe: im Run noch >c:\temp\process.txt eingefügt um zu sehen, ob das Run() überhaupt was produziert - die Datei war leer. Also ist das Run() schon nicht ok. Den Output würde ich ja vielleicht in die Variable bekommen, aber wenn nichts da ist?

    Daher: an den ""; liegt es nicht, sondern an meinem Unwissen insgesamt ;)

    WMIC path win32_process get Processid,Commandline |find "22788" > c:\temp\proxess4.txt

    Der WMIC-Befehl funktioniert in CMD . Im Ergebnis kommen dabei allerdings 5 Zeilen raus, einmal die gesuchte Commandline und die PID, danach aber noch eine Leerzeile, eine Zeile in der das FIND und die PID stehen und weitere 2.



    Und mein kurzes Script funktioniert auch nicht - habe noch nie den Output eines Run()-Befehls weiterverarbeitet:

    Optimal wäre natürlich die Rückgabe nur der zu $iPIDSearch gehörenden Commandline oder umgedreht, falls mehrfach vorkommend, Ausgabe aller PIDs, in deren Commandline $sSearch vorkommt in einem Array (noch komfortabler).

    Vielen Dank für die Unterstützung - und das am Feiertag!