Beiträge von misterspeed

Verstehst du wie GUIs in Autoit verwaltet werden? Hast du dir Beispiele zu einfachen GUIs angeschaut? Wenn ja solltest du bereits wissen, dass GUIs im MSGloop-Modus immer eine Hauptschleife haben in der guigetmsg() ausgewertet wird um z.B. Klicks auf Buttons zu erkennen. Genau in dieser Hauptschleife musst du auch die Mausposition ermitteln, sofern du diese permanent erhalten möchtest.

Dein Ziel ist also bereits erreicht, wenn du den getpos() Funktionsaufruf oben im Beispiel in der do...until Schleife einbaust anstatt per Hotkey.

Dabei wirst du dann aber feststellen, dass hier noch Optimierungspotential besteht, weil deine Anzeige Labels so viel zu schnell und oft aktualisiert werden würden und dadurch ein unangenehmes Flackern des Label controls auftritt. Um das zu vermeiden solltest du die Funktion getpos() nur in sinnvollen intervallen aufrufen (z.b. alle 100ms). Ergänzend könntest du in der Funktion auch noch prüfen ob sich im Vergleich zum vorherigen Ergebnis etwas an der Mausposition geändert hat und nur dann das Anzeige Label aktualisieren lassen.

Für eine zeitliche Drosselung schau dir diese Funktionen in der Hilfe an:

timerinit()
timerdiff()
; Alternativ könnte man auch diese Funktion nutzen
adlibregister()

Um Mausklicks zu erkennen lies bitte die Hilfe zu folgenden Funktionen:

guigetmsg()
_IsPressed()

Der Unterschied: guigetmsg() liefert nur dann Ergebnisse wenn innerhalb der GUI geklickt wird, _ispressed() liefert auch Ergebnisse wenn du in anderen Fenstern rumklickst.

Wurde hier schonmal thematisiert. Unter Windows 10 ist die Benutzerkontensteuerung restriktiver. Im anderen Fall ging es darum, dass Drag&Drop auf ein eigenes Fenster nicht mehr funktioniert wenn dieses Programmfenster selbst mit erhöhten rechten läuft, da der Anwender der die Interaktion druchführt niedrigere Rechte hat als das Programmfenster. Das selbe dürfte auch hier zum tragen kommen. Durch das #requireadmin im "send" Script wird das Script dann vermutlich auf die selbe Berechtigungsebene wie die Veeam Administratoroberfläche gebracht.

EDIT:
Hier der andere Thread von dem ich sprach --> Drag&Drop funktioniert unter Win 10 nicht

Du wolltest wissen wie man die Speicheradresse ermittelt oder etwa nicht? Die Vorgehensweise hat absolut nichts mit Autoit zu tun, somit ist die von mir vorgeschlagene Google Recherche auch dann die Antwort auf deine Frage wenn du die Daten mit anderen Mitteln oder Funktionen ausliest. Aber da du das Video nichtmal angesehen hast kannst du das natürlich nicht wissen, ganz klar mein Fehler was erwarte ich auch Eigeninitiative von dir.

Davon ab sollten die beiden Funktionen aus der genannten UDF auch heute noch funktionieren, da sie lediglich die kernel32.dll von Windows nutzen. Ein Blick in die UDF hätte genügt um das selbst festzustellen, aber diese hast du dir ja vermutlich immernoch nicht heruntergeladen. Selbstverständlich könnte es sein, dass sich seit Windows XP/VISTA/7 so einiges geändert hat und die Funktion nicht mehr richtig arbeitet, aber das müsstest du schon selbst testen und ggf. mit der memory.au3 und MSDN abgleichen. (Stichwort Eigeninitiative)

Zitat von AutoMit

(2) Wie finde ich die neue Speicheradresse, um die Zeile "$Adresse = 0x0012F590" zu aktualisieren?

Ich verweise dich nochmals auf Google. Solange du noch nichtmal im Stande bist Google richtig zu nutzen brauchen wir dir erst garnicht erklären wie man die Speicheradresse findet.

Letzter Tipp... "youtube nomadmemory.au3" -> 1. Treffer (sogar extra für dich in deutscher Sprache)

Kein Problem. Benutze Google und besorg dir darüber die 4 Jahre alten Versionen der Treibersoftware, von Autoit und der nomadmemory.au3
Schon läuft das Script. (in der Theorie zumindestens)

Zitat von AutoMit

Die "LGDCore.exe" heißt heute "Lcore.exe" - ansonsten sehe ich in dem Script keine Stolpersteine,

Ich sehe da durchaus Stolpersteine. Die Exe wird nicht nur einen neuen Namen tragen, sondern evtl. auch andere Bereiche in ihrem reservierten Arbeitsspeicher nutzen ($Adresse = 0x0012F590;). Das obige Script würde also vermutlich nur Datenmüll liefern, selbst wenn du es technisch mit Hilfe der memory.au3 oder nomadmemory.au3 zum laufen bekommst. Im Speicher fremder Anwendungen rumzuwurschteln erfordert wesentlich mehr als "copy and paste" Programmierung.

EDIT: Klar kann man diese Stelle im Speicher auch heute noch "problemlos" ermitteln und dann im Script hinterlegen, aber dafür muss man ein wenig Ahnung haben.

Zitat von AutoMit

Woher bekomme ich die aktuelle Version der NomadMemory.au3?

Also mal ernsthaft. Auch wenn man der englischen Sprache nicht mächtig ist sollte man Google bemühen können.
Google -> "nomadmemory.au3" -> 1. Treffer, 2. Posting

Ob das die letzte und neueste Version ist kann ich dir nicht sagen, interessiert mich persönlich aber auch nicht, da du per Google ohne große Mühe mit Sicherheit jedemenge weitere und evtl. aktuellere Downloads finden kannst wenn du nur 5min deiner Zeit dafür opferst.

Zitat von AutoMit

Vielleicht gibt es auch eine bessere Lösung, um die Tasten der Logitech G13 Tastatur zu erkennen?

Mars hat dir doch schon eine alternative Lösung genannt. Die Logitech Software erlaubt dir im Übrigen auch ganze Makros bzw. Tastenkombinationen für einzelne G-Tasten zu definieren. Du könntest in deinem Script also einfach eine "normale" Tastenkombination als Hotkey festlegen und dann durch Drücken der G-Taste diese komplexe Tastenkombination auslösen, worauf dein Script dann anspringen dürfte.

Was da passiert? Es wird ein Index im zuvor deklarierten Array angesprochen. Wenn du nicht weißt was Arrays sind und wie man diese nutzt lies dich im Array Tutorial von Bugfix ein: http://www.bug-fix.info/array_tut.htm

Zumindestens für "Veeam Backup" gibt es eine REST API, siehe hier: http://veeampdf.s3.amazonaws.com/guide/veeam_ba…eference_en.pdf

Ob das auch für "Veeam Endpoint Backup" gilt oder ob hier der feine Unterschied liegt kann ich dir leider nicht beantworten.

Nutzbar ist solch eine API z.B. über die winhttp UDF.

Sorry aber kritische Dinge wie Backupsoftware mit völlig unzuverlässigen Methoden zu automatisieren ist einfach nur fahrlässig.

Wenn du schon unbedingt auf GUI Automatisierung zurückgreifen musst verwende wenigstens die Control* Funktionen und verzichte auf mouseclick() bzw. send(). Mit den Control* Funktionen kannst du wenigstens sicherstellen, dass deine Eingaben im richtigen Fenster und auch im richtigen Control des Fensters landen. Die notwendigen Details des Fensters/Controls ermittelst du mit dem au3info Windowtool. Wenn du die Daten, welche du damit ermittelt hast hier postest kann man dir ggf. auch helfen die passende Funktion zu wählen und richtig anzuwenden. Manche GUIs lassen sich aber so leider nicht automatisieren, da sie keine Windows Standardcontrols einsetzen.

Grundsätzlich rate ich von GUI Automatisierung ab, denn kleine Änderungen an der GUI können dein Script schon unbrauchbar machen. Stattdessen würde ich an deiner Stelle nach Alternativen schauen. Viele Programm bieten dir zahlreiche andere Schnittstellen zur Automatisierung. Konfigurationsdateien können oftmals direkt editiert werden, evtl. in der Registry oder in einer Datenbank geändert werden. Windows Dienste sind normalerweise problemlos per cmdline neustartbar, damit Konfigurationsänderungen übernommen werden. Andere Programme bieten dir cmdline Parameter oder COM Schnittstellen (siehe Excel UDF).

Im Zweifelsfall frag beim Hersteller der Software nach welche Schnittstellen zur Automatisierung vorgesehen wurden und wie du dein Ziel möglichst zuverlässig erreichen kannst.

Die gängigen Standardsetups bieten dir "silent" Commandline Parameter. Eine GUI Automatisierung ist daher meist garnicht notwendig. Ich würde dir also empfehlen in diese Richtung zu suchen (auch in Bezug auf andere Software die du automatisiert installieren möchtest).

Wenn 3dmark einen ".MSI-Setup" hat dürften diese Paramter funktionieren: https://msdn.microsoft.com/en-us/library/…4(v=vs.85).aspx

Normalerweise ist dem eigentlichen MSI Paket nur eine hübsche GUI vorgeschaltet (setup.exe), diese macht aber letztlich nichts anderes als das ebenfalls im Verzeichnis auffindbare MSI Paket per msiexec zu installieren. Schau dir also einfach mal die Setupdateien an, evtl. wirst du ja fündig.

Hier mal eine kleine Übersicht der gängigsten Setuproutinen und deren Commandline Parameter für "silent" Intallationen:

http://www.silentinstall.org/InstallShield
http://www.silentinstall.org/inno_setup
http://www.silentinstall.org/nsis
http://www.silentinstall.org/msiexec

Sollte Futuremark ungewöhnlicherweise ein eigenes Süppchen gekocht haben und nicht auf einen der gängigen Standardsetups zurückgegriffen haben bleibt noch die Möglichkeit dort im Forum oder ggf. per Kontaktformular anzufragen ob evtl. eine "silent" Installation per Commandline Parameter vorgesehen wurde.

Zitat von AutoMit

Bitte Leute - lasst uns unsere Energie in die Lösung von Fragen stecken. Bitte.

Jupp schlag ich dir auch vor. Wäre jedenfalls sinnvoller als eine Stunde über imaginäre Bananenprobleme zu schreiben...

[Blockierte Grafik: http://i.imgur.com/H644Cfy.jpg]

Zitat von AutoMit

Wer auf (m)einem Rechner eine ini-Datei manipulieren kann, der kann noch ganz andere Dinge tun.

Es geht hier nicht nur um böswillige Manipulationen durch Dritte. Wenn du dich beim editieren der INI Datei vertippst führt das bei Nutzung von execute() zum Programmabsturz mit einer Fehlermeldung die du wenn ich mir deine anderen Themen ansehe mit Sicherheit nicht verstehen und zuordnen können wirst. Wer schonmal stundenlang nach einer Fehlerursache gesucht hat, weil ihm ein böser Tippfehler unterlaufen ist der in seltenen Fällen zum Programmabsturz führt wird verstehen wovon ich rede. Sowas passiert dir mit der von mir beschriebenen Lösung jedenfalls nicht.

Zitat von AutoMit

Dort ist nach dem bisherigen Verlauf echtes Profiwissen gefragt.

Wenn man Neuling ist sollte man etwas mehr zurückhaltend mit solchen Aussagen sein. Dir wurde in beiden verlinkten Themen von sehr erfahrenen Forenmitgliedern ausreichend Hilfestellung gegeben. Wenn du nicht bereit bis dich tiefergehend mit Autoit bzw. dem systematischen Vorgehen beim Programmieren und Erlernen einer Programmiersprache zu beschäftigen bist du hier schlichtweg falsch. Das klingt vielleicht hart aber es ist so. Du lernst absolut garnichts wenn man dir jede Kleinigkeit vorkaut und wirst uns auch in Zukunft weiterhin mit Fragen bombardieren wenn du nicht anfängst etwas mehr Eigeninitiative zu ergreifen.

Mal getestet ob der Aufruf erfolgreich ist wenn dein Autoit Script mit erhöhten Rechten läuft? (#requireadmin am Scriptanfang)

Macht zwar keinen Sinn hier Diskussionen anzufangen und hat auch nix mehr mit dem Thema zutun, aber da mir gerade langweillig ist zwei, drei Anmerkungen zu deinem Roman...

Ich habe die Variablenbezeichnungen 1:1 aus dem Beispiel des Threaderstellers übernommen. Ich kenne durchaus die ungarische Notation und dessen Sinn, wobei wir hier von Autoit reden und dank des lieben Variant Datentyps... naja lassen wir das... ich selbst nutze in meinen Scripten ebenfalls die ungarische Notation und in der Regel auch die englische Sprache. Sei also beruhigt.

Was du bei 4 Beispielcodezeilen an der Formatierung auszusetzen hast erschließt sich mir auch nicht, da gab es schlicht und einfach nichts zu formatieren.

Du brauchst mir auch nicht erzählen was Funktionen sind und wie man diese sinnvollerweise gestalten sollte. Ich bin ausgebildeter Informatiker, programmiere auch nicht erst seit gestern und habe jedemenge Fachwissen über Software Design, auch wenn ich mich beruflich entschieden habe Administrator statt Programmierer zu werden.

Ich kritisiere nicht deine Funktion, welche in der Tat sehr vieles abdeckt, sondern die Tatsache, dass du beliebigen veränderbaren Text als Autoit Code interpretierst (hoffentlich wirklich nur Strings und harmlose Makros) obwohl das hier in der konkreten Augabenstellung überhaupt nicht notwendig ist. Ohne dein Buch über "gutes" Programmieren gelesen zu haben (Korrektur es geht ja nur um "weniger schlechtes" Programmieren) kann ich mir beim besten Willen nicht vorstellen, dass dir jemand soetwas ernsthaft empfehlen würde wenn es nicht zwingend notwendig wäre oder aufgrund der Augabenstellung Sinn macht.

Nun zu deinen 11 Zeilen und 100 Makros:

Local $aReplacements[3][2] = [ ["@CRLF" , @CRLF] , ["@TAB" , @TAB] , ["@CommonFilesDir" , @CommonFilesDir] ] ; usw. kannst du gern auch mehrzeilig und mit Tabulatoren darstellen, damit es formatierungstechnisch etwas her macht und leichter erweiterbar ist


ConsoleWrite(SpecialCharReplace("...", $aReplacements))


Func SpecialCharReplace($sText, $aReplace)


  For $i = 0 to UBound($aReplace)-1
   $sText = stringReplace($sText,$aReplace[$i][0],$aReplace[$i][1]) ; ggf. noch (not)case sensitive unterscheiden... könnte man als weiteren Funktionsparamter implementieren
  Next


 Return $sText


EndFunc

Eine wunderschöne flexible Funktion um multiple Sonderzeichen aus Texten zu entfernen oder zu ersetzen, welche man auch hier im konkreten Beispiel anwenden/gebrauchen könnte.
Achja und kritisier mich jezt nicht für fehlendes Errorhandling oder die tausend anderen Dinge die man daran verbessern/erweitern könnte. Das hier dient lediglich als Beispiel und ist keine saubere ausprogrammierte Funktion. Darum geht es hier im Forum auch nicht, sondern um Hilfe zur Selbsthilfe.

Unsinn. Es ist einfach gefährlich Usercontent zur direkten Ausführung zu bringen. Sowas macht man einfach nicht, dann braucht man auch keine 20 Zeilen Code um den Usercontent halbwegs sicher zu filtern. Hier ging es lediglich darum bestimmte Steuerzeichen wie Tabulator oder Zeilenumbruch rückzuübersetzen, da es in ini Dateien Restriktionen diesbezüglich gibt.

Teste mal ob dein Script erfolgreich ist wenn du es mit Administratorrechten startest (#requireadmin am Scriptanfang)

Ich würde davon abraten hier Execute zu verwenden. INI Dateien sind beliebig editierbar, dadurch kann man alles mögliche durch einfaches Editieren der INI Datei zur Ausführung bringen.
Die bessere Lösung wäre hier mit stringreplace() zu arbeiten.

$Zeile = IniRead ($ini_Datei, $ini_Section, $Schluessel, "")
$Zeile = stringreplace($Zeile,"@CRLF",@CRLF)
$Zeile = stringreplace($Zeile,"@TAB",@TAB)
; usw.

Achja und ganz wichtig noch... sorge dafür, dass die sockets beim Verbindungsende/abbruch geschlossen werden tcpcloseSocket() und bei Programmende ein tcpshutdown(). Andernfalls kann es passieren, dass deine verwendeten Ports nicht mehr nutzbar sind und weitere Tests dadurch scheitern.

Keine Ahnung was du da machst. Wieso hast du in beiden Scripten Server und Client code? Für eine einfache Kommunikation reicht es völlig wenn es einen Server gibt und der bzw. die Clients sich mit diesem verbinden. Das was du hier versuchst ist dann schon eher P2P und wird in der Praxis nicht funktionieren wenn du nicht auf allen beteiligten Geräten statische IPs verwendest. Bei dynamischer IP Zuweisung bräuchtest du für sowas noch eine zentrale Stelle die dir die aktuellen IP Adressen verrät.

Ohne deine Scripte nun besonders genau angeschaut zu haben könnte ich mir auch vorstellen, dass du ein Timing Problem hast. Sprich dein Client sendet etwas bevor der Server überhaupt bereit ist Antworten anzunehmen/auszuwerten.

Fang nochmal ganz von vorne an und bau dir eine kleine GUI für den Server und den Client über die du den Verbindungsaufbau und das Senden manuell auslösen kannst. (kleiner chat client, welcher automatische antworten vom server bekommt)
So kannst du deinen code in beiden Scripten prüfen und besser verstehen was da eigentlich passiert.

Achja und du solltest am Server Computer prüfen ob evtl. eine Firewall oder Antivirenlösung dein Serverscript blockiert.

Hier nochmal der ungefähre Aufbau der Scripte:

; Server-Script


$mainsocket=TCPlisten(...)


do
$clientsocket=TCPaccept($mainsocket)
until $clientsocket <> -1 ;.... 1 client hat sich verbunden


; wenn du mehr als eine client verbindung willst musst du die client sockets in einem Array
; speichern und TCPaccept permanent aufrufen


while 1
 $msg=TCPrecv($clientsocket) ; auf nachricht vom client prüfen
checkclientmessage($msg) ; nachricht prüfen und antworten
wend


func checkclientmessage($msg)
;...
tcpsend($clientsocket) ; antwort an client schicken
;...
endfunc

; Client-Script


$serversocket=TCPconnect(...)


while 1
 $msg=TCPrecv($serversocket) ; auf nachricht vom server prüfen, z.B. "hallo du bist verbunden"
checkservermessage($msg) ; nachricht prüfen und antworten
;... zum testen könntest du nun deine client gui überwachen und je nach benutzer aktion dinge an den server schicken, sofern der server etwas damit anfangen kann antwortet er dir
wend


func checkservermessage($msg)
;...
tcpsend($serversocket) ; automatische antwort an server schicken, z.B. "mein name ist"
;...
endfunc

Also wirklich... man kann auch gleich auf ein Array verzichten und alles in einen einzelnen String packen. Geht alles, macht nur keinen Sinn. 2D Arrays haben durchaus ihre Berechtigung und können sehr hilfreich sein. Zeig mir mal wie du ein 1D Array nach einem bestimmten Attribut filterst oder sortierst wenn du erstmal die Strings auseinanderfrimmeln musst. Geht natürlich alles... aber mit welchem unnützen Rechen- und Zeitaufwand? Davon ab kolidieren Trennzeichen gerne mal mit den eigentlichen Werten, was zusätzliche Prüfungen oder entsprechend als sicher einzustufende Trennzeichen erfordert.