Beiträge von Grimli

    So,


    das Ergebnis als Pointer zurück zu geben scheint der richtige Weg zu sein, zumindest frisst er das problemlos. Ob das jetzt 0-terminiert sein muss oder nicht, da habe ich keinen Unterschied festgestellt.


    Jedoch ergibt sich dadurch jetzt ein weiteres Problem: Nach der resolveModuleFn-Funktion nimmt eine loadModuleFn-Funktion das Ergebnis entgegen.


    Diese Funktion habe ich wie folgt als Callback registriert:

    Code
    $loadModuleFnHandle =    DllCallbackRegister("_LoadModuleFnCallback",    "ptr",  "ptr;str")


    In der Funktion selbst mache ich nur ein ConsoleWrite und gebe Null zurück.


    Bei der Ausführung kommen nur kryptische Zeichen raus.

    Wenn ich den zweiten Parameter auf "ptr" setze sieht es zumindest richtig aus, jedoch weiß ich nicht wie ich an die richtigen Daten komme.


    Versucht habe ich bereits den "Pointer" zu nutzen um mir wieder ein Struct damit zu befüllen, dabei kommt aber nur das gleiche wie bei dem ersten Versuch raus.


    Allerdings fällt mir auf das AutoIt immer mit einem Fehler abzustürzt, normalerweile würde ich von der WrenVM eine brauchbare Fehlermeldung bekommen. Daher vermute ich mal das ich etwas bei den Pointer/Speicher Dingen falsch mache.



    Das ist der Code der beiden Funktionen in Wren die für resolve/load genutzt werden:


    Hilft vermutlich auch nicht wirklich, da dort recht viele Makros genutzt werden mit denen ich nicht viel anfangen kann.

    Value von der Funktion resolveModule ist als bsp. ein `uint64_t`, vermutlich genutzt als Adresse für einen Pointer, aber da komme ich leider nicht ganz mit.


    In C/C++ wäre das bestimmt viel einfacher mit dem Speicher :)

    Moin,


    mit deisem Code bricht die DLL scheinbar weg, AutoIt beendet sich mit Errorcode -1073740940.


    Ich habe mehrere Versuche getestet:

    - DllStructGetPtr($tRet) --> Fehler

    - DllStructGetPtr($tRet, 1) --> Fehler


    Danach nochmal mit der ersten Methode, was funktioniert. Liegt das evtl. an dem Speicher den AutoIt fuer den String freimacht? Das ggf. die DLL etwas schneller war als AutoIt beim aufräumen?


    Die Methode hatte ich schon versucht, jedoch den Struct NUR mit StringLen($sRet) definiert, also zu kurz.


    Hallo zusammen,


    Ich habe mir, zur Übung, eine kleine UDF für die Skriptsprache Wren geschrieben. Dabei bin ich auf folgendes Problem gestoßen:


    Um Module in die VM von Wren zu laden werden einige Callback Funktionen verwendet, welche zur Initialisierung der VM mit gegeben werden müssen. Das funktioniert soweit und meine AutoIt-Funktionen werden sauber gestartet.


    Bei dem Versuch ein Modul in Wren zu importieren (`import "win32" for Registry` als Beispiel) werden 2 Callback-Funktionen aufgerufen, die erste um den Pfad aufzulösen. die zweite zum eigentlichen Laden.


    Die erste Funktion (`resolveModuleFn`) hat folgende Signatur:

    Code
    typedef const char* (*WrenResolveModuleFn)(WrenVM* vm, const char* importer, const char* name);


    Also gehe ich davon aus das ich meine AutoIt-Funktion wie folgt erstelle:

    Code
    Func _ResolveModuleFnCallback($pVM, $sImporter, $sModule)
        ; do stuff
        Return "some-resolved-module"
    EndFunc
    
    Local $ResolveModuleFnHandle = DllCallbackRegister("_ResolveModuleFnCallback", "str", "ptr;str;str")


    Wie gesagt, das funktioniert auch alles. Die Callback-Funktion wird aufgerufen und tut ihr Arbeit.

    Jedoch wirft mir die Wren-VM danach einen Fehler, dass das besagt Modul nicht gefunden werden konnte. Laut dem C-Code wäre der Rückgabewert NULL.


    Mache ich hier irgendetwas falsch oder sollte ich eher in dem C-Code von Wren nach einem Fehler suchen?



    Im Anhang findet Ihr das Repo von Wren im "main"-Branch.

    Die DLL sowie der AutoIt-Code sind im Ordner "\lib" zu finden. Kompiliert habe ich das ganze mit VS2022, falls Ihr die DLL lieber selbst erstellen wollt :)


    P.S.: ich nutze AutoIt-x64, falls das Skript "test_x64.au3" nicht laufen sollte.


    Gruß

    Hoffentlich meinst du damit nicht, das im VBScript zu machen, denn das wird nichts. In VBScript gibt es keine Timer, die alle x ms ein Event auslösen. (Ironischerweise gibt es eine Funktion, die sich "Timer" nennt, aber nur die Zeit seit Mitternacht ausliest, oder so ähnlich.) :( Deshalb könnte man nur eine Schleife mit Sleep benutzen, was oft ungewollte Effekte erzeugt.

    Ich dachte da eher an eine einfache Funktion die das AutoIt Skript startet, ggf. mit einer Überprüfung der PID, um sicher zu stellen das die Kommandos auch beim COM-Objekt ankommen.


    Ich habe noch auf mehreren Wegen versucht an die anderen Funktionen von PsPad ran zu kommen, jedoch ohne Erfolg. Um diese nutzen zu können müsste man sich einen Weg suchen wie das VBScript abfragt ob der AutoIt-Teil eine PsPad Funktion ausgeführt haben möchte. Dabei fällt mir aktuell aber nur eine Schleife ein, was jedoch unschöne Effekte im PsPad hervor ruft.


    Bisher hast du es geschafft, den markierten Text aus dem SynEdit zu lesen. Wenn du es auch noch hinkriegst, die Hintergrundfarbe zu setzen für mehrere Fundstellen des markierten Textes, dann bist du der Held! Das Ganze ziel darauf ab, das Feature zu ermöglichen, zum markierten Wort alle identischen Wörter zu highlighten. (Das kennt man z. B. aus SciTE.)

    Was das angeht denke ich nicht dass das funktionieren wird. Ich kenne mich mit PsPad nicht so gut aus, bisher scheint er nicht über eine solche Funktion zu verfügen. Auch der Ansatz bei einer Suche dynamisch den Highlighter zu ändern wird, wenn es denn überhaupt machbar ist, schwierig da ich keinerlei Funktion gefunden habe die das ermöglichen würde.

    Ob das SynEdit Steuerelement sowas unterstützt kann ich nicht beurteilen, evtl. weiß da der Entwickler von PsPad mehr darüber.


    Wirklich schade das PsPad keine Events für die Skripte unterstützt, damit wäre vieles einfacher. :(

    Ich würde, um den Code zu starten, entweder eine a3x oder exe Datei nehmen. Da du für deine Erweiterung ja eh davon ausgehen musst das AutoIt installiert ist, sollte das kein Problem darstellen.

    Das VBScript muss noch ordentlich erweitert werden, beispielsweise würde ich eine Funktion zum Ausführen des AutoIt Skripts einbauen. Zudem würde ich empfehlen die Prozess-ID zu speichern, damit diese überprüft werden kann. Sollte der AutoIt Teil nämlich nicht mehr laufen bekommst du unschöne Fehler.


    Mit einem Editor-Objekt von PsPad zu arbeiten ist kein Problem, jedoch habe ich es bisher nicht geschafft auch die "globalen" Funktionen erreichbar zu machen.

    Das Gleiche gilt wohl auch für die Log, Project und FTP Funktionen, das habe ich aber nicht getestet.


    Alles in Allem bin ich damit nicht ganz zufrieden, aber immerhin geht ein Teil.
    Und der Lernfaktor ist durchaus angenehm :)

    Moin,


    ich habe etwas gebastelt und bin, nach vielen vielen Versuchen, endlich an den Text und auch alles andere ran gekommen.

    Leider ist der Weg dahin nicht ganz einfach, aber machbar.


    Du brauchst folgendes (im Anhang):

    1. AutoItObject.au3
    2. PsPadExt.au3
    3. AutoItScriptExtension.vbs (umbenennen)


    • Um das ganze zu testen musst du zuerst das VBScript zu PsPad hinzufügen.
    • Dann startest du das AutoIt Skript "PsPadExt.au3".
    • Jetzt PsPad starten und Datei bearbeiten, test markieren
    • In der AutoIt Gui auf den Button klicken
    • freuen :)


    Hier nochmal die Skripte als Text:


    Ich hoffe das hilft dir weiter, mein Gehirn braucht erstmal eine kleine Pause :S



    Gruß

    Moin,


    ich habe heute eine ganze Weile mit AutoItObject gespielt (erneut).


    Folgende Option hättest du:

    Du kannst mit AutoItObject ein Com-Object im ROT (Running Object Table) erstellen und auf dieses aus den JScript / VBScript Skripten zugreifen.

    Auf diesem Wege könntest du dir eine kleine Brücke zwischen den beiden Welten schlagen.


    Ich habe es eben nur mit einem kleinen Snipsel probiert, aufwändigere Aktionen müsste man testen.

    Falls Bedarf und Interesse besteht werde ich gern ausführlicher.


    Gruß

    Guten Morgen,


    Danke fuer's testen. Ich habe die Ausfuehrung der UserFunction entsprechend umgebaut.

    Da die test.au3 leider recht unuebersichtlich ist und in der Form nicht ausreicht um sinnvoll zu testen werde ich noch einige Testcases erstellen muessen.

    Dann sollte auch eher ersichtlich sein wozu das Ganze ueberhaupt gut sein soll.


    Wenn ich soweit bin wuerde ich mich freuen wenn Ihr wieder darueber schauen koenntet.


    Gruss

    Ich habe das Skript eben direct runter geladen, nicht das es zu verwechselung kommt.


    AutoIt
    ------------------------------1---------------------------2-------3--------3-2-4------------------4----1
    $sTemplatePath = StringReplace( $sTemplatePath, $item[0], ( $vData($item[2]) ) ( $item[3], $vData )    )

    Die Klammerpaare sind so korrekt, der 3te Parameter ist mit Sicherheit etwas verwirrend: ($vData($item[2]))($item[3], $vData), das ist noetig damit ich auf die Funktion in $vData($item[2]) zugreifen kann. Das ($item[3], $vData) sind die Parameter fuer die besagte Funktion; die Parameter Anzahl fuer die Funktionen ist bisher nicht dokumentiert.

    Ich benutzte, hauptsaechlich, das ISN AutoIt Studio. SciTE nur bei kurzen Skripten und meist nur in der Standard Ausfuehrung vom AutoIt-Setup.


    Soweit ich das sehen kann ist die Syntax, laut AutoIt-Help, richtig; funktionieren tut das Skript auch.

    Ist das dann Fehlinterpretation von AU3CHECK?

    Hallo,


    vermutlich war die Frage etwas unklar gestellt oder es weis wirklich niemand was.


    Wie dem auch sei; ich habe mich nach laengerer, erfolgloser Suche, selbst an Eine UDF versucht.

    Im Anhang findet Ihr das erste Ergebnis.


    Es waere schoen wenn das mal jemanden testen mag, evtl. auch in eigenen Skripten und sagt was gut/schlecht ist und wo noch "potenzial" ist.


    Gruss

    Moin zusammen,


    hat oder kennt jemand Eine UDF mit der ich String-Templates parsen kann, aehnlich wie mit Mustache?

    Natuerlich kann ich mir das ganze mit Regexp selbst bauen, suche aber nach einer eher universellen Loesung.


    Zudem finde ich es sehr interessant das Mustache (zmd. in JavaScript) auch Funktionen im Template unterstuetzt.


    Gruss

    Man kann ja bei einem solchen Projekt durchaus auch mehrere Repositories pflegen. Das ähnelt ja etwas einer klassischen Linux-Paketverwaltung, da gibt es auch zig Repos.

    Mehrere Repos wuerde ich auch befuerworten, denkbar sind auch Meta-Repositories um mehrere Repos zusammen zu fassen.

    Ich versuche das Thema moeglichst verstaendlich im englischen Forum zu posten, mal sehen wie dort der Anklang dazu ist.


    /EDIT:

    Hier der Link aus dem englischen Forum, falls es jemand verfolgen moechte: https://www.autoitscript.com/f…it-packagemodule-manager/

    Hallo zusammen,


    ich habe mir darueber ein paar Gedanken gemacht und wuerde Euch gern ein, zwei Ansaetze aufzeigen. Waere nett wenn Ihr euch das mal in Ruhe durchlest und mir sagt was Ihr davon haltet.


    Ansatz 1: Projektdatei

    Der erste Ansatz ist art Projektdatei, nennen wir sie udfm.ini.

    Ein rein fiktives Beispiel:

    Code
    [Project]
    title = Steam Backup Manager
    name = steam-bm
    repo_type = svn
    author = Churanos
    runtime_version = >=3.3.14.5
    
    [Dependencies]
    AspirinJunkie/JSON = *

    Dabei wird, aehnlich wie bei anderen package managers, ueber den Eintrag [Dependencies] die UDF samt Version (falls noetig/sinnvoll) eingetragen. Diese werden dann via console command herunter geladen und in ein Verzeichnis vendor innerhalb des Projekts gespeichert. In dem Hauptskript wird nur noch eine Zeile als Include eingetragen: #Include "vendor/autoload.au3". Ueber console commands wie add oder install koennen via console auch UDFs nachgeladen werden, die dann automatisch in die udfm.ini oder einer Lockdatei geschrieben werden.

    Dieser Ansatz aehnelt dem von PHP/Composer.


    Ansatz 2: Alternatives Praeprozessor Komando

    Bei diesem Ansatz wird ohne Projektdatei gearbeitet. In den AutoIt Dateien wird eine UDF mit #uses "AspirinJunkie.JSON" referenziert. Via console command werden alle *.au3 Dateien nach dieser Direktive gescannt und alle UDFs herunter geladen, gespeichert werden die Dateien wie im ersten Ansatz.

    Nun gibt es 2 weitere Moeglichkeiten:

    1. Die #uses Direktive wird gegen ein #Include ausgetauscht.
    2. Es wird wie im ersten Ansatz weiterhin eine autoload.au3 genutzt.

    Der AutoIt Compiler ignoriert die #uses Direktive daher spricht, aus meiner Sicht und um den Verwaltungsaufwand gering zu halten, die Umsetzung von Punkt 2 eher an.



    Ich hoffe Ihr koennt mir folgen. Fuer Eure Ideen, Kritik, etc. waere ich dankbar.


    Gruss

    Mars Da fehlte meinerseits etwas Text; ich stimme dir da zu, ein Standard-Header fuer die Forenposts macht sinn.

    Ich bezog mich nur auf die Header der UDFs, die sind natuerlich jedem selbst ueberlassen.


    Wenn es hier eine Sammelstelle geben wuerde, waere ich bereit mir die Muehe zu machen die angelegten UDF-Posts in ein System zu uebernehmen, sofern/sobald es ein solches gibt.

    Vielleicht kann man so auch einige zur Mitarbeit bewegen.


    Unabhaengig davon werde ich mich wohl mal an einen kleinen Prototypen machen, vielleicht kommt ja was sinnvolles bei raus ;)