Beiträge von Yjuq

    Hi, wir sind ein Programmierforum für die Programmiersprache AutoIt. Wir haben erst mal prinzipiell nichts mit Autos am Hut. Aber vielleicht bekommst du dennoch eine hilfreiche Antwort von jemanden. Lediglich als kleine Info für den Fall dass dir garkeiner antworten sollte.


    LG. Yjuq

    Naja, das ist auch ganz simpel. Im prinzip werden die neuen Events gefetcht nachdem du GuiGetMsg() aufrufst. Demnach musst du es nur aufrufen und auf Events reagieren:


    Sleep() verhindert aber das sofortige schließen. Ist genauso ein Fall den du nicht in Events setzen möchtest. Hier mal eine Variation mit einen richtigen Timer:


    Solche Sachen lassen sich aber mit einer "Manager" Funktion, welche AutoIt Skript von dem Windows Events trennt, ziemlich einfach lösen.

    Du solltest in Windows Events prinzipiell keine Schleifen verwenden. Das sorgt nur dafür dass sich das Programm aufhängt und Events nicht mehr richtig funktionieren.

    Stattdessen kannst du eine Variable in dem Event setzen um dann deine gewünschte Funktion aufzurufen:


    Noch schöner (und bei einer größeren GUI) ist natürlich eine Funktion die das managed.

    Wenn du Probleme mit Deutsch hast: Ich bin auch der englischen Sprache mächtig, falls das für dich angenehmer ist. Du darfst mir auch gerne private Nachrichten über das Forum schreiben. Ich antworte sobald ich diese sehe. Bin aber eher einer der mehr inaktiven Mitglieder hier. Ich brauch AutoIt nicht mehr so häufig wie ich es mal gebraucht hatte.

    Den Kommentar zu der "Spieleautomation" oder wie du es nanntest "Spielautomaten" bezieht sich auf Programme, welche darauf abziehlen Computerspiele zu automatisieren. Dies widerspricht den Forenregeln und wird hier nicht geduldet. Das hat nichts mit einem Casino zu tun. ^^


    Die Dokumentationen sind manchmal schwer zu verstehen wenn man den Sinn hinter einigen Sachen nicht kennt oder Vergleichsbeispiele hat. Weißt du was über Elektrotechnik und wie Logic-Gates funktionieren? Diese Bit-Funktionen machen genau das Selbe, lediglich mit mehreren "Signalen" gleichzeitig. Du kannst dich ja mal ein wenig hier durchwühlen: Logic Gates


    Es gab da auch eine gute Deutsche Seite über Elektrotechnik. Aber mir fällt der Name nicht mehr ein... Sorry

    Musashi - Ich denke eine vorgefertigte Lösung zu präsentieren hilft nicht wirklich. Ich bleibe mal bei meiner Vorrangehensweise und erkläre ihm lieber wo seine Fehler sind. Alles andere macht für mich keinen Sinn.


    dask - Deine Antworten sind zumindest schon einmal nicht schlecht. Ich habe dir die Fragen gestellt um selber erst mal zu sehen ob du auch selber verstehst was du da gepostet hast. Prinzipiell scheinst du ja schon mal gewisse Grundlogik und ein allgemeines Verständnis von Progammabläufen zu haben. Sprich: Geordnete Gedankengänge von "Was will ich erreichen?" zu "Wie setze ich das um?". Das ist schon einmal eine gute Vorraussetzung. Nun zu deinen Fehlern die du mit dem Skript gepostet hast.


    Frage 1:

    Das ist soweit korrekt. Diese Zeile macht auch genau das, was du beschrieben hast.


    Frage 2:

    Das ist prinzipiell auch korrekt. Zumindest wenn es um die Logik dahinter geht. Jedoch ist das nicht korrekt umgesetzt. In der Programmierung existieren Strings. Strings sind auf gut Deutsch eigenlich nur Zeichenketten. In AutoIt werden Strings üblicherweise in " oder ' Zeichen verpackt. Was du tatsächlich abfragst ist Folgendes: Ist $iColor nicht gleich der Zeichenkette "Hex(C9C9C7)"? Du fragst hier nach der Zeichenkette ab, nicht nach dem Hexwert C9C9C7. Das ist schon ein Fehler. Was du eigentlich machen möchtest ist das hier: $iColor <> 0xc9c9c7


    Um einen Hexdezimalen Wert in AutoIt darzustellen, kannst du einfach 0x vorne heran fügen. Die Funktion Hex() gibt dir den Hexdezimalen Wert einer Dezimalzahl zurück. Konvertiert also von Dezimalsystem zu Hexdezimalsystem. Der Rückgabewert ist allerdings ebenfalls ein String. AutoIt ist sehr freundlich was Datentypen angeht, meistens jedenfalls. Bedeutet dass "123" und 123 für AutoIt in Vergleichen das Selbe ist.


    Hex() - Dokumentation


    Frage 3:

    Das Grundprinzip von Schleifen scheinst du zu kennen. Die Formulierung ist etwas üppig und nicht wirklich korrekt, aber ich sehe was du damit ausdrücken möchtest. Vom Sinn her ist das richtig.


    ---


    Nun kommt der Knackpunkt in deinem Skript. Du fragst lediglich einmalig ab, welche Farbe an der Koordinate (738 | 822) befindet. Diese Farbe wird in $iColor gespeichert. Danach überprüfst du ob sich $iColor irgendwann einmal verändert. Das Problem ist allerdings, du fragst niemals nochmal nach der Farbe an besagter Koordinate. Heißt, dein $iColor bleibt immer gleich und deine Abfrage in der While-Schleife gibt demnach immer das Selbe Ergebnis zurück. Um das zu umgehen musst du $iColor in der While-Schleife aktuallisieren.


    ---


    Andy - Tja, da warst du mal wieder schneller... x)

    Hi o/
    Willkommen im Forum!

    Dein Code funktioniert nicht weil es einige Fehler beinhaltet. Wir geben hier normalerweise Hilfe zur Selbsthilfe, das bedeutet du bekommst (zumindest von mir) die grobe Richtung vorgegeben. Den Rest must du dir aber selber erschließen.


    Da es dir wahrscheinlich an Grundlagen mangelt, fangen wir doch einfach mal mit einem einfachen Fragespiel an:


    Was macht Local $iColor = Hex(PixelGetColor(738,822,1),6)?

    Was macht While $iColor <> "Hex(C9C9C7)"?

    Was ist eine While-Schleife?


    Und zu letzt: Was möchtest du eigentlich erreichen?

    Kannst du das genauer erläutern?

    Ich meine damit dass es keinen generellen Parser gibt den du für jede Programmiersprache einfach nutzen kannst. Einen JSON Parser in Form einer DLL zum Beispiel. Stattdessen hat jede Programmiersprache eine eigene Implementation dafür.


    https://www.json.org/json-en.html


    Scroll mal runter auf der Seite, da fängt es schon an. Sagen wir mal, ich hab jetzt eine Programmiersprache die keinen JSON Parser von sich aus hat, viel spaß den Parser zu schreiben.

    Ich hatte keineswegs die Absicht, dein Werk madig zu machen

    Huh, davon bin ich auch nicht ausgegangen. Text im Internet ist sowieso immer schwierig zu interpretieren wenn es um die momentane emotionslage des Author geht. ^^


    Hauptsächlich sollte mein Beispiel demonstrieren wie das Dateiformat funktioniert, nicht welche Vorteile es gegenüber anderen bietet und welche Nachteile. Darum geht es auch gar nicht. Das ist nur entstanden da ich einen spezifischen Anwendungsfall hatte wo vorhandene Dateiformate schlichtweg versagen oder es eben kein Parser dafür existiert für meine genutzte Programmiersprache. Beispiel JSON - Es gibt zwar zig implementationen, diese sind aber alle Programmiersprachen spezifisch.


    Welp, es musste was her was extrem einfach zu parsen ist. Letzten endes ist das ganze gestern Nacht in einer halben Stunde entstanden. xD

    Vielleicht solltest du mal eine Bsp. generieren, dass die erforderliche Flexibilität beinhaltet. Das hier gezeigte Bsp. ist (deutlich einfacher lesbar) auch in einer INI abbildbar.

    Verstehe dein Einwand nicht. Die INI Datei zwingt dich in folgendes Format:

    [Section]

    Key=Value


    Kommentare müssen mit einen ; am Zeilenanfang beginnen


    Zumal es auch nicht möglich ist folgendes zu machen:

    [Section]

    Key==Value


    Wie kann ich den Key jetzt "Key=" nennen und den Value auf "Value" setzen?


    Kurz, die INI und dazugehörigen AutoIt Funktionen schränken dich ein. Mein Format soll eben das Problem umgehen. Es geht hauptsächlich darum die Einschränkungen, wie die Datensätze in der Datei hinterlegt werden müssen, lockerer zu gestalten. Ich hab meine Gründe dazu und auch sogar ein Anwendungsfall wo die INI schlichtweg versagt. Ich dachte ich teile meine Gedanken dazu weil ein Parser für diese Variante schnell geschrieben ist.

    Hallo o/


    Aus verschiedenen Gründen brauchte ich ein Dateiformat, welches Hauptsächlich Konfigurationen speichert. Mein erster Gedanke war logischerweise eine simple *.ini Datei. Jedoch war das Format leider noch viel zu unflexibel für mein Vorhaben. Andere Dateiformate waren und sind auch viel zu kompliziert (z.B. JSON) um schnell mal einen Parser dafür zu schreiben. Also hatte ich mir überlegt, wie kann man ein Dateiformat so simpel wie möglich halten und dennoch sämtliche Möglichkeiten offen halten?


    Lustigerweise hatte ich dann auch eine Idee. Der Parser dazu war auch schnell geschrieben (obwohl dieser sicherlich mit String Funktionen um einiges schneller wäre). Ich nenne das Format Yjuq's File Format oder kurz: YFF - *.yff


    Das Prinzip dieses Formates ist extrem simpel. Du wählst dir dein Delimeter und Escape Zeichen aus. Man kann sich auch mehrere aussuchen. Zu einfachen Demonstationszwecken benutze ich folgende:

    Delimeter: < und >

    Escape: \


    Alles was zwischen den Delimeter ist wird als Datensatz gewertet, alles was direkt nach einem Escape Zeichen in einem Datensatz kommt, wird ebenfalls als Datensatz gewertet. Das bedeutet dass die Escape Zeichen hauptsächlich dazu dienen, ebenfalls die Delimeter als Datensatz zu erkennen. Logischerweise kannst du damit auch Escape Zeichen als Datensatz werten lassen. Alles andere, was nicht zwischen Delimeter steht, wird schlichtweg ignoriert.


    Dieses Dateiformat erlaubt es das Dateiformat frei zu bestimmen und dennoch die Datensätze zu deklarieren. Die ignorierten Zeichen können als Kommentare genutzt werden oder für weitere Datensätze für andere Delimeter und Escape Einstellungen. Da bleibt es eurer Fantasie überlassen.

    Hier einmal ein Beispielskript mit dem Parser dazu:

    Der Parser selber schmeißt euch einfach eine Liste mit allen Datensätzen zu. Im Index 0 ist immer die Anzahl der Datensätze im Array. Wie Ihr die Datensätze interpretiert bleibt euch überlassen. Hier mal ein einfaches Beispiel um Daten im Key = Value Format zu speichern:

    Und hier das Skript:

    Nun denn, für meine Zwecke jedenfalls nutzbar. Ich dachte ich teile das mit euch. Wer einen besseren Parser schreiben möchte, nur zu. Ich hantiere mit eine kleine Menge an Daten dh. reicht mir die Geschwindigkeit aus. Jedoch würde ich mich natürlich über ein free update freuen. :P


    Hauptsächtlich geht es bei dem Post darum eine einfache Möglichkeit zu haben Datensätze in menschenlesbarer Form zu speichern und abzurufen. Dabei sollte das Format nicht kompliziert sein aber funktionsreich genug um auch Datensätze zu erzeugen die via Software dann richtig aufbereitet werden können. Eine einfache Array Liste reicht da meiner Ansicht nach aus. Darauf lassen sich weitere Filter und Bedingungen anknüpfen um das Dateiformat zu extenden. Sprich: Datensätze weiter auswerten und entsprechend so zu kategorisieren wie gewünscht.

    Hey, guck mal hier: https://www.autoitscript.com/f…ge-runtime-clr-framework/


    Damit kannst du auf die .NET DLL zugreifen. Alternativ kannst du auch einen eigenen Treiber schreiben. Ich bezweifel dass es dazu schon eine Ansteuerung in AutoIt existiert.


    Ich bin jedoch ein wenig Suchfaul, wenn du mir den Sourcecode zu der .NET DLL liefern kannst, kann man damit bestimmt was machen. :P


    https://www.plenom.com/downloads/download-software/#sdk - Da ist auch eine USB API dabei, guck mal ob du damit nicht was anfangen kannst.

    Ich hatte dazu mal einen Beitrag geschrieben: RE: PandaRunner Reworked - Ein Autoit Game


    Für jene die es interessiert.

    Woha, ich mag die Idee. Ich glaube ich mache mir daraus ein Live Wallpaper. :P


    Ich werde da auch mal ein an einer Version basteln. Gerne Teile ich dir dann meine Lösungsansätze mit. Wenn du ggf. Grafiken brauchst könnte ich welche machen. Dauert nur je nachdem wie ich Lust & Zeit habe.

    Naja, du kannst den Datenverkehr im USB port mitschneiden wenn du lust hast. Würde daraus hinauslaufen dass du dann einen eigenen Treiber für das Gerät schreibst. Ich bezweifel dass der Hersteller des kartenlesegerätes irgendwo eine öffentliche Dokumentation dafür hast, also müsstest du schon selber herausfinden müssen wie das Gerät die Daten überträgt. :P


    Die einfachste und schnellste Lösung:

    Druck doch einfach in eine Datei. Diese kannst du dann so aufarbeiten wie du es benötigst.


    Aber ja, prinzipiell könntest du das mit AutoIt lösen... Mit genug Aufwand. xD


    Ehrlich gesagt bin ich da gerade ziemlich dran interessiert. Einen Treiber habe ich bis dato noch nicht geschrieben. Wenn du die Zeit & Lust hast können wir es ja mal versuchen. Ich habe halt nur nicht den Kartenleser hier, weshalb sämtliche Tests du übernehmen müsstest.

    Was ist der Unterschied zwischen _WinAPI_PathFindFileName und _WinAPI_PathStripPath.

    Beides mal bekomme ich doch den Dateinamen als Ergebnis.

    Hi Tweaky, es ist richtig dass beides prinzipiell das gleiche Ergebnisse liefern. Der Hauptunterschied ist jedoch dass die WinAPI in PathFindFileName einen String zurückgibt (genauer gesagt einen Pointer). PathStripPath hingegen überschreibt den angegebenen String. Das ist in etwa das Äquivalent zu ByRef in AutoIt.


    So ungefähr. AutoIt jedoch hat bei der PathStripPath Variante schlichtweg einfach einen Rückgabewert stattdessen hinzugefügt. Warum jedoch beide Funktionen in der WinAPI existieren kann ich dir nicht sagen, das wird mir aus der Dokumentation nicht ersichtlich.


    https://docs.microsoft.com/en-…shlwapi-pathfindfilenamea

    https://docs.microsoft.com/en-…nf-shlwapi-pathstrippatha


    Gruß :)

    Ich würde dir vorschlagen deinen Post nochmal durchzulesen und zu überlegen, ob dir irgendwer anhand dieser Beschreibung helfen kann. Am einfachsten ist es eigentlich immer Fragen hier im Forum folgendermaßen zu stellen:


    --


    Hi,


    Ich möchte gerne folgendes umsetzen:

    - Beschreibung 1

    - Beschreibung 2

    - Beschreibung 3

    - etc...


    Folgendes habe ich versucht bzw. das sind meine Lösungsansätze:

    - Versuch 1

    - Versuch 2

    - Versuch 3


    Hier noch einige Screenshots / Quellcode / zusätzliches Material:

    - Daten 1

    - Daten 2

    - Daten 3


    Hat jemand eine Idee wie ich das am besten umsetze?


    ---


    Das hilft uns erst einmal zu verstehen wo genau das Problem liegt und ob dein Lösungsansatz überhaupt der passende für dein eigentliches Vorhaben ist. Zumal liefert es auch die notwendigen Informationen um dir konkret helfen zu können. Es ist auch immer gut schon vorab Background Informationen zu liefern. Das heißt, was möchtest du machen? Wieso willst du das machen? An welche Parameter sind wir gebunden, wo können wir ggf. andere Dinge vorschlagen (vielleicht ein anderes Programm benutzen)? etc...


    Kannst du ggf. meine Frage mit diesen Informationen beantworten?

    --> Ich habe ein Rezept. Dort ist als Zutat Äpfel gelistet. Ich habe keine Äpfel, mit was kann ich diese ersetzen?


    Zitat

    Wie komme ich dennoch an die notwendigen / versteckten Infos, um dann die jeweiligen Buttons/Boxen ganz gezielt anzusteuern?

    Keine Ahnung. Das liegt an dem Programm was es anzusteuern gilt. Im schlimmsten Fall existiert ja immernoch _ImageSearch().


    ---


    Tendenziell ignoriere ich in den meisten Fällen Fragestellungen, welche mir nicht direkt mitteilen können was sie wollen. Erfahrungsgemäß bin ich da länger dran beschäftigt die notwendigen Informationen einzuholen, als an einer Lösung zu arbeiten. :)


    Das ist auch nicht böse gemeint. Es hilft uns direkt ein klares Bild zu bekommen was der Fragestellende möchte. Zudem hilft es dir jemanden schneller zu finden der deine Frage auch beantworten kann.

    Das liegt daran dass Windows gerne mal solche Dateien daran hindert den Content zu laden. Das lässt sich ziemlich einfach beheben.


    Dazu gehst du einfach in dein AutoIt Installationsverzeichnis (Standardmäßig: C:\Program Files (x86)\AutoIt3) und machst ein Rechtsklick auf der Datei AutoIt.chm. Dort wählst du die Eigenschaften aus.


    Dort müsstest du folgendes sehen können:


    Dort einfach auf Zulassen klicken und mit OK oder Übernehmen das ganze speichern.


    Gern geschehen.



    €dit:

    RIP... Da gibt man sich mal halbwegs mühe. xD