Zeig doch mal dein Script her, dann können wir dir sicherlich besser helfen.
Beiträge von alpines
-
-
Edit: Muss man in GDI nicht die Ressourcen wieder aus dem Arbeitsspeicher werfem,
nachdem man das Programm beendet hat?
Windows gibt die automatisch frei wenn der Prozess beendet wird. Nichtsdestotrotz ist es ein schlechter Stil geöffnete Handles nicht wieder zu schließen.
-
Es ist zwar toll, dass du das in verschiedenen Sprachen implementiert hast aber es besteht dadurch letzlich kein wirklicher Mehrwert bis auf die Möglichkeit mal zu sehen welche Grafiklibraries man wo ganz einfach verwenden kann.
Visual Basic / C# .NET und Java bieten dir z.B. Klassen an, und statt die Funktionen einfach rüberzupasten und so anzupassen, dass sie funktionieren, hätte ich das Spiel lieber für die Sprache neugeschrieben mit Klassenelementen z.B. Spielfeld, Schlange, Bonus und Gegenstände z.B. Wände wo man gegenlaufen kann.
Man hätte zeigen können, welche Aspekte eine Sprache auszeichnen und die zum Vorschein bringen können.
-
Ich möchte verhindern, dass meine Exe durch eine andere ausgetauscht werden kann.
Da gibt es soviele Möglichkeiten wie Sandkörner am Strand.
Du kannst in deinem Programm eine Variable erzeugen mit einem bestimmten Inhalt und dann von einem anderen Programm aus, an der Speicherstelle auslesen ob der Inhalt dem String entspricht den du im 1. Programm eingetragen hast (sofern keiner dein Programm aufbricht und nachschaut sollte dieser String in anderen Programmen nicht zufällig auftauchen).
Du kannst die Exe-Datei hashen und schauen ob der Hash dem entspricht, den du im Programm hinterlegt hast, wenn nicht, dann wurde die Datei offenbar verändert.
Du kannst den Shield in das Programm selber implementieren und so eine zweite Exe überflüssig machen.
Du kannst auf dem Dateisystem eine Datei hinterlegen wenn der Shield anläuft und löschen wenn er beendet wurde.
Es gibt unzählbar viele Wege, such dir einfach was aus.
-
Ich hatte vorhin schon geschrieben, dass du dafür WinList verwenden kannst. Damit kannst du alle Fenster die existieren abfragen.
-
Ja kannst du, halt mal das Finder Tool von AutoIt Window Info auf das Fenster drauf und schau bei Summary mal nach was unter "Text" steht, dort tauchen Labels und Eingaben auf.
Eventuell musst du noch das Opt "WinTextMatchMode" anpassen um den Text zu finden.
-
Dann würde ich aber auf keinen Fall nach dem Programm selber suchen, damit deckst du viel zu wenig ab.
Du solltest intern Sicherheitsmechanismen implementieren, wenn deine Werte im Programm plötzlich springen wegen Hacking oder Eingaben getätigt werden (von virtuellen Eingabegeräten), dann würde ich einfach das eigene Programm direkt beenden.
Aber einen eigenen Anti-Cheat zu schreiben wird nicht sehr einfach, da hat man anfänglich mehr Löcher als ein Schweizer Käse.
-
Darf ich fragen was du wo zu machen versuchst? Das hört sich alles irgendwie komisch an.
-
Das ist aber bestimmt ganz schön cpu fressend oder?
Sind ja einige Prozesse.
Naja, du suchst einmal und dann hast du dein Fenster.
-
Öffne die txt doch mal mit dem Notepad oder einem anderen Editor und lösche die Datei. Klappt auch..
Das liegt aber daran, dass Notepad die Datei vollständig einliest, somit ist kein Lock auf die Datei notwendig. Speichert man, so wird die Datei neu geöffnet.
Es findet also kein Streaming in die Datei statt.
-
Dafür brauch ich doch aber den Namen von Window oder versteh ich das falsch?
Und den Text der enthalten ist. autoiter hat nur die halbe Lösung gepostet, mit der Funktion kannst du den Prozess des Fensters ausfindig machen.
Wenn du aber nur die Kontrollspezifikation hast (Class, Instance) musst du jedes Fenster durchgehen (mit WinList) und dann mit ControlCommand und IsEnabled schauen ob das Control vorhanden ist.
-
Dann hat man es "schlampig" umgesetzt
So manche Entscheidung des Development Team ist fragwürdig, leider ist AutoIt nicht Open-Source also können wir das als Forenprojekt nicht forken und selber weiterentwickeln.
Da hilft nur Symptome bekämpfen (UDFs entwickeln die das richtige machen) und weiter, außer man macht sich die Mühe einen eigenen Interpreter zu schreiben (vielleicht sogar einen Compiler bzw. Übersetzer zu C/C++ o. ä. und dann compilen). Da gabs auch schon Ansätze dazu, siehe AutoItC.
-
Du kannst das im BugTracker von autoitscript.com melden, such erstmal nach einem existierenden Ticket welches sich mit deinem Problem beschäftigt.
Wenn es keins gibt kannst du ein neues erstellen. Ich bin mir aber ziemlich sicher, dass es bereits dazu eins gibt und sie es, wenn es keins gibt, es nicht ändern werden.
Da gabs aber offenbar schon was dazu: https://www.autoitscript.com/trac/autoit/ticket/546
-
Seltsam, ich hatte natürlich vorher gesucht, aber wenn ich bei Google "Autoit+_WinAPI_LockFile" oder auch "Autoit+WinAPI LockFile" eingebe, kommt bei mir kein autoitscript-Hilfetreffer. Bei "Autoit+_WinAPI_FileInUse" hingegen schon !
Du musst einfach nur nach "autoit _winapi_lockfile" suchen, du kannst in fast allen Fällen sogar das Keyword "autoit" weglassen, da die Nomenklatur der UDFs beinahe einzigartig ist und sich nur in seltenen Fällen mit anderen Funktionen überschneidet. Entweder kriegst du dann auch die AHK-Funktionen als Ausgabe und/oder die msdn-Seite dazu.
Musashi, dann versuchs mal mit ner anständigen Suchmaschine statt mit dem Allerweltsgeschwür.
Wenn man falsch sucht, dann braucht man auch nicht auf die richtigen Suchergebnisse zu warten, eine Suchmaschine ist nur so intelligent wie die Anfragen die man ihr schickt.
-
Zu _WinAPI_LockFile und _WinAPI_UnlockFile habe ich allerdings keine Hilfe gefunden.
https://www.autoitscript.com/autoit3/docs/l…PI_LockFile.htm
https://www.autoitscript.com/autoit3/docs/l…_UnlockFile.htm
Da sind sie doch? Ich schätze mal die UDF war vor der Wrapperfunktion da, ansonsten hätte man direkt die _WinAPI-Funktion aus der internen UDF nehmen können.
Die ist ja auch schon 5 Jahre alt.
-
Du musst die Datei auch dementsprechend sperren: https://www.autoitscript.com/forum/topic/13…t-process-only/
-
Es reicht also aus, die VC Runtimes 2015 (x86 und x64) zu installieren !
Du kannst auch einfach die DLL in das selbe Verzeichnis packen (oder irgendwo im Windowsordner) und dann hast du das gleiche Ergebnis.
Ich habs nicht gerne, wenn auf meinem Rechner 50.000 Runtimes drauf sind, wenn eine DLL fehlt lade ich sie einzeln runter und schiebe sie ins Verzeichnis.
-
Und das heisst was?
Dass du keine Arrays mit Variablen vergleichen kannst wie du Variablen mit Variablen vergleichst. Du musst einen Index des Arrays angeben, ansonsten wird das nichts.
Das sind die Grundlagen von AutoIt, vielleicht solltest du sie dir nochmal anschauen.
-
Ach ja, meine FB Version benötigt für das HD Amsel Bild ca. 400ms, wobei ich den Weg über Arrays genommen hatte (hinzufügen, sortieren und zählen).
Kannst du mal deine Variante umprogrammieren, so dass du sie nicht sortierst? Ich hatte ja ein AutoIt-Script bereits dazu am Anfang gepostet,
wenn du so viele Indizes wie Farben erzeugst, dann fällt die Suchzeit weg und aus 400ms sollten deutlich weniger werden.
-
If $aPos = $aActionAreas[0][1] then
$aPos ist ein Array, keine Variable.
