Beiträge von Yjuq

    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

    Und dennoch ist es doch seeeehr seltsam, dass Imagesearch als erste Funktion den Anfängern ins Auge springt.

    Wieso landen Anfänger bei der Fülle der Funktionen gerade dort?! Das setzt gezielte Suche voraus und ebenso einen Plan, was man tun will.

    Ich habe noch nie erlebt, dass man "zufällig" auf das Pixelgedöns stößt und sich sagt: Geil, hier kann ich was Lernen. :Face:

    Wer Lernen möchte, arbeitet Tutorials durch, programmiert Bsp. aus der Hilfe nach und verändert sie etc.

    Insofern ist ein Misstrauen in solchen Fällen angebracht und fast immer begründet.

    Nö, eben nicht. Das Problem ist, dass du als Anfänger erst gar nicht weißt was überhaupt existiert und welche Suchbegriffe du brauchst um überhaupt das zu finden was du auch tatsächlich benötigst. Es fehlt schlichtweg das Wissen dazu. Wenn ich mich an meine Anfangszeit zurückdenke bin ich Haufenweise eben auf diese Funktionen gestoßen. Klar, erst einmal suchst du so generelle Sachen wie "AutoIt Tutorial Deutsch" oder soetwas. Nachdem du dir dann ein wenig Basic Wissen rein gepumpt und sowieso nix verstanden hast, fängst du an Dinge machen zu wollen. Was vermeintlich einfaches. z.B. Dinge anklicken, Maus bewegen, in Notepad schreiben, vielleicht mal Usereingaben entgegen nehmen und deine erste Messagebox ausgeben.


    Zwangsläufig landest du dann irgendwann nach langer suche auf eben diese Funktionen. Sie sind einfach zu verstehen als Anfänger, benötigen sonst nicht so viel Code drum herum und geben dir ein direktes Feedback. Anfänger wissen nicht was sie falsch machen, also gehen viele schlichtweg davon aus dass sie einfach die falsche Funktion haben und suchen weiter. Oder fragen dann mal in Foren nach.


    Ich beobachte schon seit längeren dass ihr Teilweise Anfänger einfach rausgrault. Klar, viele Fälle sind gegen die Forenrichtlinien - das ist soweit auch ok. Aber auch einige false positives. Das weiß ich daher, weil ich diese Anfänger meist dann noch abgreife und ihnen privat Hilfe anbiete. Es stellt sich eher heraus dass diese einfach nicht wissen dass statt dem ImageSearch vielleicht doch ein ControlClick besser wäre (oder gar existiert). Zumal wissen die meisten auch gar nicht was sie wollen. Sie probieren einfach momentan nur aus. Das gehört zu der Lernphase dazu.


    Was ich lediglich sagen möchte ist: Stellt eure Fangfragen, ja. Seit aber nicht immer so stark voreingenommen. :d


    Es sei denn ihr wollt ein exklusiver Club bleiben.

    Prinzipiell kann ich dir bei deinem Vorhaben helfen. Allerdings müsstest du dafür erst einmal konkret beschreiben was du machen möchtest.


    Zitat

    Wenn du z.B. zusätzliche Menüpunkte in eine Software durch Hooking integrierst, verwendest du die Software nicht mehr bestimmungsgemäß. Der Autor hat für seine Software ein bestimmtes Verhalten und Aussehen bestimmt. Da darf man nicht ohne Weiteres dran basteln.

    Das kommt darauf an um was für eine Software es sich handelt und welche Lizenzen damit verbunden sind. Zudem darfst du für die reine Weiterbildung so ziemlich vieles machen. Aber das ist eine andere Geschichte. Lassen wir Ihn doch erst mal erklären was sein genaues Vorhaben ist, dann können wir ja immernoch feststellen auf welchen Zweig wir uns bewegen.


    Zitat

    Hat sich schon mal jemand mit dieser - zugegebenermaßen komplizierten - Thematik befasst und wenn ja, mit welchem Ergebnis?

    Ja, hab ich. Sehr umfangreich sogar. Ich bin in der Lage vorhandene Software so anzupassen wie es mir gefällt. Das sollte als Einschätzung reichen. Wenn dich das Themengebiet einfach nur interessiert kann ich dir anbieten Software zur Verfügung zu stellen je nach Bedarf. Oder schreib dir eigene kleine Programme wo du dran rumspielst.

    Ich kann da BugFix nur zustimmen. Ich würde auch ein komplett anderes Design vorschlagen. Wenn ich dein Vorhaben richtig verstanden habe, kommt du da mit deutlich weniger Arbeit weg als wie dir vielleicht bisher klar ist. Prinzipiell unterscheidest du erst einmal zwischen statischen und dynamischen Objekten in deiner Software. Die statischen Dinge werden programmiert, die dynamischen generiert.


    Ist in deinem Fall ziemlich einfach. Fangen wir mal mit den statischen Dingen an:


    Das GUI Layout. Wie soll die Anzeige aussehen und wo sollen die Hauptelemente platziert werden? Du brauchst etwas um die Maschinen anzuzeigen. Du brauchst etwas um einige Maschinendaten tabellarisch darzustellen und du brauchst etwas um verschiedene Dokumente zu diesen Maschinen zu öffnen. Das ist erst mal fix und bildet dein Grundgerüst. Ich würde dir folgendes empfehlen:

    - Eine Liste um die Maschinen aufzulisten: ComboBox oder ListBox

    - Eine Tabelle für deine Daten die du anzeigen möchtest: ListView

    - Eine Auswahl für das Dokument welches dazu geöffnet werden soll: ComboBox, ListBox oder ListView


    Für das Design kannst du dir alles mögliche ausdenken. ich würde einfach links eine ListBox hinklatschen für die Maschinen Auswahl, in die Mitte die ListView für die tabellarische Ansicht und rechts einfach noch ne ListBox für die Dokumente. Das Design programmierst du einfach ein und lädst die notwendigen Daten später dynamisch rein. Kannst ja noch ein bisschen verschönern indem du das Fenster vergrößerbar machst, sodass die Mitte (also die ListView) sich mit vergrößert. Die beiden Ränder (die ListBox) kannst du einfach statisch auf ne gewisse Breite setzen und alles in die Höhe mit vergrößern lassen. :P


    Dann brauchst du eine Datenbank in der du einfach hinterlegst, was du nun in die GUI laden möchtest. Das schöne daran ist dann später, du brauchst einfach nur deine Datenbank anpassen und brauchst dein programm nicht neu zu kompilieren wenn Anpassungen zu technischen Daten notwendig sind. Die einfachste Form ist einfach eine *.ini Datei. Dafür bietet dir AutoIt ja schon Funktionen an. Da auf der Seite sind genug verlinkungen zu den anderen notwendigen Funktionen - wird schon.


    Das Schwierigste ist, sich Gendanken zu machen wie diese *.ini Datei am besten aufgebaut sein sollte. Ich würde das Ganze einfach folgendermaßen machen:

    Irgendwie sowas in der Richtung. Kann man bestimmt auch noch geschickter machen. Dann brauchst du die Daten nur noch einlesen und abspeichern und schon kannst du alle Sachen geschickt in deiner GUI ausfüllen und die Dokumente per ShellExecute aufrufen und die Sache ist geritzt. Ist eigentlich prinzipiell ziemlich einfach zu realisieren. Aber da du das ja als Projekt machen möchtest um die Sprache zu erlernen, darfst du nun selber rausfinden wie alles geht. ;)


    Ich hoffe ich konnte dir einen Denkanstoß in die richtige Richtung geben. Bei unklarheiten, Problemen etc. darfst du gerne nachfragen. Wir beißen nicht, lecken aber mal ein wenig :P

    Du kannst das Fenster einfach vergrößern z.B. mithilfe von WinMove(). Du musst aber definieren wie die Controls sich zu resizen haben via GUICtrlSetResizing(). Ist eigentlich nicht so schwer - Hier mal Quick & Dirty:


    Ich würde das einfach in ein Array packen und dieses dann sortieren.



    Der Rest ist einfach dann nur noch das Array auslesen und so formatieren wie gewünscht.