Self Modifying Code / IPC / Funktionen zur Laufzeit erzeugen

  • Hallo zusammen,

    Grob: ich möchte dem User die Möglichkeit geben, innerhalb eines AutoIt-Programms AutoIt-Code anzulegen und auszuführen. Dabei sollen globale Daten und Funktionen des Hauptprogramms genau so einfach verfügbar sein, als hätte der User die Funktion stattdessen vor Programmstart in Scite getippt.

    Bevor ich weiter aushole: Es gibt durchaus Alternativen zu so einer Vorgehensweise (DllCallbacks, mehrere Scripte, IPC, andere Sprachen) - die sind mir bekannt. Aber oben gezeigtes Beispiel verdeutlicht so ziemlich genau, was ich suche. Ich wiederhole noch einmal: Dabei sollen globale Daten und Funktionen des Hauptprogramms genau so einfach verfügbar sein, als hätte der User den Code stattdessen vor Programmstart in Scite getippt. Das beinhaltet Schleifen, Globale variablen, Funktionsaufrufe, AutoIt Funktionen, byRef Parameter, DllStructs, - das volle Programm.

    Die Gründe dafür sind unterschiedlich und nicht verhandelbar :)

    Spoiler anzeigen

    Einer der Hintergründe als Beispiel: u.a. werden vom User zur Laufzeit "Business Objekte" in meinem Programm erstellt (dazu auch noch einmal mehr hier) - dazu gibt es eine grafische Oberfläche. Nachdem ein Business Objekt im Programm erstellt wurde, werden benötigte Files im Hintergrund generiert (XML Definitionen mit Eigenschaften und Methoden, AutoIt Scripte mit Funktionen, etc.). Das "Business Objekt" wird dann mittels AutoItObject instanziiert und kann als "echtes" Objekt in AutoIt verwendet werden.

    Damit die im Objekt definierten Methoden (=Funktionen) aber aufgerufen werden können (das neue, frisch generierte Include ist ja noch nicht "eingebunden"), muss das Script prinzipiell neu starten. Die Include-Anweisung für das neue File vorausgesetzt - die wird auch automatisch eingefügt. Dafür gibt es in meiner Applikation einen entsprechenden Workaround (neue Objekte werden "ausgelagert" - intern relativ umständlich.)

    Grob funktioniert das in Etwa so - nur zur Veranschaulichung.:

    Code
    ; AllObjects.au3


    Ich habe nun erst einmal folgende Lösung speziell in meiner Applikation erarbeitet:

    1) Mittels AutoItObject wird ein "Container" erzeugt - z.b. um Daten zu übergeben oder Callbacks auszuführen. Dieser Container wird mittels _AutoItObject_Register global in Windows bekanntgemacht.

    2) Externe Funktion wird generiert (Script per FileWrite angelegt etc.)

    3) Im externen Script wird der erzeugte Container "abgeholt" (um auf Daten zuzugreifen, etc.) und ein zweiter Container wird erstellt. Die "generierte" Funktion wird als Methode zu diesem zweiten Container hinzugefügt.

    4) Das Hauptprogramm wird benachrichtigt , holt sich diesen zweiten Container, ruft die Methode auf und übergibt sich selbst als Parameter.

    FYI Das ganze habe ich jetzt auch noch einmal hier im englischen Forum (inkl. "UDF") beschrieben. Vielleicht ist dieser Workaround ja schon mal für irgendwen hilfreich.

    Nun meine Frage:

    Kennt jemand einen einfacheren / besseren Weg um Funktionen zur Laufzeit zu generieren und dabei Daten/Funktionen Scriptübergreifend verfügbar zu machen?

    Ich habe auch versucht, Funktionsreferenzen (a la $oVar = _MyCustomFunction) zwischen den Scripten hin und her zu reichen, aber das klappte nicht gut.

    Danke für jeden Hinweis,

  • So ganz werde ich nicht schlau. Je mehr ich darüber nachdenke welche Lösung die beste für dich ist umso mehr Fragen tauchen auf. Die wohl wichtigsten hier:

    Müssen es AutoIt Skripte sein? Kannst du nicht einfach Lua einbinden? Müssen diese Skripte independent laufen? Also eigenständige Programme? Oder nur reine Funktionssammlungen? Müssen unbedingt COM Objekte erstellt werden? Dürfen die eingebundenen Skripte uneingeschränkten Zugriff haben, oder sind da einige Beeinträchtigungen notwendig?

    Es gibt da einige Wege um das zu realisieren. Je nach Anforderung ist das eine besser geeignet als das andere. Aber es kommt wirklich sehr stark darauf an was genau gefordert ist. Kannst du mehr Informationen geben? Oder eine genauere Erläuterung über das System in welches es intigriert werden soll? Je mehr Informationen um so besser.

    Um ehrlich zu sein schreit das alles bisher nach Lua für mich.

  • Moin,

    Danke für die Antwort!

    Müssen es AutoIt Skripte sein?

    - Ja

    Kannst du nicht einfach Lua einbinden?

    - Nein. Außerdem verstehe ich noch nicht, wie ich das Problem mit den geteilten Daten dann besser löse.

    Müssen diese Skripte independent laufen? Also eigenständige Programme? Oder nur reine Funktionssammlungen?

    - Prinzipiell braucht nichts als eigentständiges Script laufen, wenn es denn eine andere Möglichkeit gibt, das Coding einer AutoItObject-Methode zur Laufzeit zu definieren.

    Müssen unbedingt COM Objekte erstellt werden?

    - Nein. Aber es müssen AutoItObject Objekte sein. - Technisch gesehen sind das aber keine COM Objekte.

    Dürfen die eingebundenen Skripte uneingeschränkten Zugriff haben, oder sind da einige Beeinträchtigungen notwendig?

    - Uneingeschränkt. Also entsprechend der Sichtbarkeit von Attributen und Methoden der Objekte - da kümmert sich AutoItObject dann drum.

    Es gibt da einige Wege um das zu realisieren. Je nach Anforderung ist das eine besser geeignet als das andere. Aber es kommt wirklich sehr stark darauf an was genau gefordert ist. Kannst du mehr Informationen geben? Oder eine genauere Erläuterung über das System in welches es intigriert werden soll? Je mehr Informationen um so besser.

    Ich freue mich über konkrete Vorschläge.

    Das System, in das diese Skripte integriert werden sollen, ist ein ERP System auf Basis von AutoItObject. Das heißt die gesamte Anwendung, und alle Daten/Funktionen sind in Objekte gekapselt ( - ich benutze das Wort "Objekte" ab hier quasi-äquivalent zu "Klassen"). Es gibt da sozusagen

    - Systemobjekte (z.B. "Application", "Database", "ObjectBuilder", "Printer", etc.) und

    - Businessobjekte (z.B. "Material", "Materialprice", "Customer", "Salesorder", "Materialtext", "Contract", "Invoice", "ContractReleaseOrder", etc.).

    Die Systemobjekte sind fix und kapseln nur die Applikation und alles was "im Hintergrund" läuft.

    Die Business-Objekte werden zur Laufzeit erstellt: Long Story short: Am Anfang der Applikation wird ein Verzeichnis mit XML-Dateien ausgelesen. Für jede Datei wird ein entsprechendes AutoItObject-Objekt erstellt, ggf. eine Datenbanktabelle erzeugt, Referenzen auf andere Objekte aufgelöst, etc. Die Dateien werden noch von Hand erstellt aber das ultimative Ziel ist die Pflege in einem eigenen Screen in der Applikation.

    Spoiler anzeigen

    Die Business-Objekte sehen zum Beispiel so aus - heir mal ein "material". Also ein Artikel oder eine Dienstleistung, etc. Das besteht wiederum aus einem Materialtext und einem Materialpreis, der wiederum aus einem Kunden und einem Preis besteht, etc., etc., etc.

    Spoiler anzeigen

    Aktuell ist es so, dass - wenn ein neues Business Objekt gefunden wurde - eine Include-Anweisung in einem Sammelinclude eingefügt wird. Das Programm wird dann nach Aktualisierung der Objekte neugestartet . Es läuft unkompiliert, also geht das.

    Spoiler anzeigen

    Die Business Objekte können dann im Programm genutzt werden und miteinander interagieren. Teilweise sind sie miteinander verbunden, übernehmen Attribute, Methoden oder Werte voneinander, etc. AutoItObject ist da echt flexibel. Beispiel: Ein Material kann abhängig von dem Kontext, in dem es erstellt wurde (ein Material speziell für einen Kunden, ein Material in einem Beleg, ein Material in einem Abruf, etc.), andere Attribute haben.

    Spoiler anzeigen

    Dieses wäre ein Beispielscript, das ein User erstellen können sollte. Das Objekthandling klappt alles ganz gut. - Aber es ist nicht schön, dass man keine neuen Business-Objekte anlegen kann, ohne die Anwendung neu zu starten. Ich hoffe das erklärt den Sachverhalt besser.

    Ich kann aus Lizenzgründen keine lauffähige Version hier im Forum posten.

    Viele Grüße

  • Das schreit sogar noch mehr nach Lua nach deiner Erklärung und dem Beispielskript welches User anlegen könnten...

    Was du vor hast ist AutoIt als embedded Language zu benutzen. Das kannst du knicken ohne komplette Systeme dafür zu intigrieren und IPC zu betreiben. Der Grund dafür ist, dass AutoIt Code nun mal nicht einfach zur Laufzeit geladen und ausgeführt werden kann (mit geteilten Daten). Wenn es nur um Attribut Zuweisungen geht würde ich eher ein einfaches Datenformat vorschlagen was stattdessen geladen wird. Aber da auch Funktionen und Logik vermutlich ausgeführt werden soll wird das ganze kniffliger. Lua ist für solche Vorhaben konzipiert.

    Das heißt nicht dass es dafür keine Lösungen gibt, sind aber um einiges aufwendiger als schlichtweg Lua zu intigrieren. Aber bleiben wir mal bei der AutoIt Variante wenn du sagst Lua ist komplett ausgeschlossen. Ich habe gerade nur nicht viel Zeit, deshalb nur eine knappe Antwort. Ich melde mich aber nochmal. o/

    €dit:

    Zitat

    - Nein. Außerdem verstehe ich noch nicht, wie ich das Problem mit den geteilten Daten dann besser löse.

    Falls sich doch daran was rütteln lässt kann ich dir gerne ein Beispiel diesbezüglich schreiben. Ist eigentlich nicht so schwierig mit Lua.

    3 Mal editiert, zuletzt von Yjuq (10. Februar 2021 um 13:43)

  • Wenn Du mir ein Beispiel geben könntest, wie ich auf folgendes Objekt in Lua zugreifen kann (+ also some_data auf einen anderen Wert setzen und die some_method()-Methode aufrufen), könnte ich zumindest schauen, ob das eine Möglichkeit ist.

    Spoiler anzeigen

    Ich könnte auch VB oder C# oder Javascript mittels des Dotnetrunners einbinden - aber eigentlich wollte ich mir so eine Krücke mit einer zweiten Sprache ersparen. Das ist nicht cool für den Anwender. Wahrscheinlich würde ich eher vorrübergehend die in AutoIt geschriebenen Scripte in Lua oder VB übersetzen und dann beim neustart die "echten" autoit sources einbinden. Aber dann klappt auch mein aktueller Umweg mit dem zweiten Script und _AutoItObjectRegister ganz gut.

    Wenn Du mir was zusammenstellst, kann ich sehen, wie gut es passt oder nicht.

    Danke,

  • Hallo. Das Thema scheint recht komplex und ich kann im Moment keine Lösung anbieten, da es mein Wissen und meine Erfahrung übersteigt. Aber wenn ich darf hätte ich wahllose Gedanken zu bieten, die vielleicht Anregung für weitere Ideen sind. :)

    Wie gesagt, mein Wissen über AutoItObject ist sehr bescheiden. Ich benutze z.B. AutoItServer.au3 aus dem Thread "Access AutoIt" von trancexx. Für mich sind eher COM ROT Objekte wichtig, z.B. hier von LarsJ, wobei interesannte Aspekte unter "Usage" beschrieben sind, z.B. gleich der erste Punkt "Passing array between AutoIt programs".

    Ok, ich denke, es war für dich nicht leicht, eine so komplexe Sache auf eine einfach verständliche Erklärung zu reduzieren. ;) Wie dem auch sei, für mich kann es nicht einfach genug sein. Deshalb sei bitte nicht böse, wenn ich dumme Fragen stelle, ich versuche ja zu helfen. :saint:

    1. Die wichtigste Frage für mich: Müssen die "Module" (Scripte die die Klassen der Business Objekte enthalten) unbedingt in das Haupt-Modul/Script inkludiert werden? Wenn sie z.B. weiter als separate Module laufen können, braucht es keinen Neustart der Anwendung.

    2. Kann ein AutoItObject-Object zur Laufzeit erweitert werden? Kann also ein zur Laufzeit erstelltes Modul seine Eigenschaften und Methoden dem bestehenden Au3-Objekt hinzufügen?

    Verstanden habe ich, dass das dein Anliegen ist:

    Kennt jemand einen einfacheren / besseren Weg um Funktionen zur Laufzeit zu generieren und dabei Daten/Funktionen Scriptübergreifend verfügbar zu machen?

    In einem Script verwende ich ein Dictionary als COM ROT Objekt zur IPC zwischen AutoIt und VBScript. Ein Dict kann als KeyValues, glaube ich, so ziemlich alles aufnehmen, auch Arrays und Objekte. Vielleicht könnte man so deine Au3-Objekte in allen Modulen verfügbar machen. ...

    ... Oder nur die Daten. Z.B. könnte man die Module "lauschen lassen", ob ein bestimmter Key im Dict gesetzt ist, und falls True dann seine entsprechende Funktion ausführen (Parameter können ebenfalls im Dict übermittelt werden) und das Ergebnis (die Daten) im Dict speichern. Das Haupt-Modul holt sie aus dem Dict und verarbeitet sie. Nach meiner Erfahrung ist die Kommunikationsgeschwindigkeit zwischen den Modulen akzeptabel.

    - Wie gesagt, ich denke nur mal laut, vielleicht ist es ja auch Unsinn.

    Ich hätte noch weitere Gedanken, aber abhängig von deinen Antworten werden einige davon überflüssig. 8o

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

  • Hey,

    Wie gesagt, mein Wissen über AutoItObject ist sehr bescheiden. Ich benutze z.B. AutoItServer.au3 aus dem Thread "Access AutoIt" von trancexx. Für mich sind eher COM ROT Objekte wichtig, z.B. hier von LarsJ, wobei interesannte Aspekte unter "Usage" beschrieben sind, z.B. gleich der erste Punkt "Passing array between AutoIt programs".

    Mir ging es da bis vor kurzem Ähnlich - ich habe mich bis vor diesem Projekt auch nicht mit AutoItObject beschäftigt - es ist schon frech, wie gut und schnell man damit komplexe Anwendungen baut. Der Hinweis auf ROT lässt mich ein bisschen schmunzeln, denn das ist genau die Technik, die in meinem Workaround in Post 1 genutzt wird. Dabei hatte ich mich auch von Access AutoIt insprieren lassen.

    1. Die wichtigste Frage für mich: Müssen die "Module" (Scripte die die Klassen der Business Objekte enthalten) unbedingt in das Haupt-Modul/Script inkludiert werden? Wenn sie z.B. weiter als separate Module laufen können, braucht es keinen Neustart der Anwendung.

    Nein - und tatsächlich habe ich gestern schon überlegt, ob es nicht eleganter wäre, die Objekte in eigene "Worker" auszulagern. Oder wenigstens die ObjectFactory-Klasse, die Objekte erstellt. Dann müsste nur diese neu starten und nicht die GUI Applikation. Die Idee gefällt mir.

    2. Kann ein AutoItObject-Object zur Laufzeit erweitert werden? Kann also ein zur Laufzeit erstelltes Modul seine Eigenschaften und Methoden dem bestehenden Au3-Objekt hinzufügen?

    Ja! Man kann zu jedem Zeitpunkt eine Methode oder ein Attribut hinzufügen oder die Sichtbarkeit ändern (und wahrscheinlich auch löschen) - aber ich glaube man kann keine Objekte "kopieren".

    Das einzige Problem tritt hier auf, wenn das Objekt nicht im aktuellen Prozess erstellt wurde.

    Heißt: Übergebe ich ein Objekt mittels ROT and ein anderes Script, kann ich dort nur noch Methoden aufrufen und Eigenschaften ändern; aber keine neuen erstellen.

    Deswegen gibt es in meinem initialen beispiel auch 2 Objekte: Das Objekt, das aus dem Hauptscript kommt (ROT Server), ist im zweiten Script (ROT Client) quasi halb-schreibgeschützt.

    In einem Script verwende ich ein Dictionary als COM ROT Objekt zur IPC zwischen AutoIt und VBScript. Ein Dict kann als KeyValues, glaube ich, so ziemlich alles aufnehmen, auch Arrays und Objekte. Vielleicht könnte man so deine Au3-Objekte in allen Modulen verfügbar machen. ...

    Mit dem Dict habe ich bisher kaum gearbeitet. Vor allem nicht im ROT Kontext.... Kannst Du in beiden Scripten (also server und client) KeyValues hinzufügen und löschen, bzw. sortieren usw.?

    PS: Zum Thema IPC hatte ich nun das hier gebaut:

    https://www.autoitscript.com/forum/topic/20…ct-pure-autoit/

    PPS: Die ursprüngliche Frage bleibt aber eigentlich bestehen - denn am schönsten wäre eine Möglichkeit, dass ich überhaupt nichts irgendwohin auslagere oder neustarte, sondern irgendwie zur Laufzeit eine Funktion "foo" generiere, die ich mit z.B Call("foo") eine Zeile später aufrufen kann. ( - oder an _AutoItObjects_AddMethod) übergeben... :)

    Danke Euch!

  • Dann möchte ich dich gleichmal auf ein Problem hinweisen, das leider nicht lösbar ist und mich viele Nerven gekostet hat: AutoIt-Object -- Parameter einer Methode als ByRef

    Danke - das ist in der Tat eine der Limitierungen, die mich bisher gehindert hat, es zu testen. Bisher macht sich das Geschwindigkeitstechnisch kaum Bemerkbar. Hier wird aber auch nocht mit verhältnismäßig kleinen Datenmengen gearbeitet. Erstens sind die Objekte sehr schmal, und zweitens sind es nur eine Handvoll Belege. Mal sehen, ab wann das ByRef Problem zum Problem wird. :thumbup:

  • Mit dem Dict habe ich bisher kaum gearbeitet. Vor allem nicht im ROT Kontext.... Kannst Du in beiden Scripten (also server und client) KeyValues hinzufügen und löschen, bzw. sortieren usw.?

    Tja, da sehe ich nun, wie wenig ich weiß. Ich dachte, dass AutoItObject NICHT im ROT registriert wird und dann steht da im Header von "_AutoItObject_RegisterObject()" in der "AutoItObject.au3" dick und fett: "Registers the object to ROT". Aber ich weiß auch sehr wenig über ROT. "The Running Object Table (ROT) is a system global table where objects can register themselves. This makes the objects accessible in processes other than the process where the object was created."

    So hat mich z.B. verwundert im Zusammenhang mit ROT über Server und Client zu lesen. In meinem Fall, wo ich ein COM ROT Dictionary Objekt benutze, braucht es keinen Server in dem Sinne. Ein Standard-Objekt wird erstellt ObjCreate("Scripting.Dictionary") und im ROT registriert $oRunningObjectTable.Register($iFlags, $pObject, $pMoniker, $iHandle). Danach ist das Dictionary in allen Scripts zur Verfügung, die das "Zauberwort" kennen, also der Moniker (Name) unter dem man das Dict im ROT registriert hat.

    z.B. in AutoIt: $g_oDict_COM = ObjGet($sCOM_ROT_Name) ; Dictionary object

    oder in VBScript: Set oCOM_Dict = GetObject(gc_sCOM_ROT_Name)

    Das könnte man in weiteren Scripts mithilfe des Monikers abholen und benutzen, über Script-Sprachen-Grenzen hinweg. In meinem Fall zur IPC zwischen AutoIt und VBScript. Ein Server/Client oder Sender/Receiver Szenario ist dabei nicht nötig, da es sich um eine "zwei"-Wege-Kommunikation handelt. Eigentlich um eine mögliche Kommunikation zwischen allen Scripts, die auf das Dict zugreifen. Jeder kann lesen und schreiben und alles ist quasi "ByRef" (nicht wörtlich nehmen!). - Vielleicht verstehst du nun meine Faszination. :)

    Was dein Thema betrifft, so dachte ich dabei an die Möglichkeit, die du beschrieben hast mit "tatsächlich habe ich gestern schon überlegt, ... die Objekte in eigene "Worker" auszulagern".

    2. Kann ein AutoItObject-Object zur Laufzeit erweitert werden? Kann also ein zur Laufzeit erstelltes Modul seine Eigenschaften und Methoden dem bestehenden Au3-Objekt hinzufügen?

    Ja! Man kann zu jedem Zeitpunkt eine Methode oder ein Attribut hinzufügen oder die Sichtbarkeit ändern (und wahrscheinlich auch löschen) - aber ich glaube man kann keine Objekte "kopieren".

    Das hört sich doch schonmal gut an.

    Das einzige Problem tritt hier auf, wenn das Objekt nicht im aktuellen Prozess erstellt wurde.

    Heißt: Übergebe ich ein Objekt mittels ROT and ein anderes Script, kann ich dort nur noch Methoden aufrufen und Eigenschaften ändern; aber keine neuen erstellen.

    Bist du sicher, dass es sich so verhält? Meiner Vorstellung nach sollte ein ROT Objekt für alle Scripts gleich verfügbar sein. Vielleicht wird das Objekt im aktuellen Script nicht geändert (im Sinne von aktualisieren des bestehenden Objekts) sondern neu erstellt? - Bedenke, dass ich hierbei nur rate, mein Wissen reicht dafür nicht aus! :( Aber vielleicht liest ja jemand mit, der sich besser auskennt. :rock:

    PS: Zum Thema IPC hatte ich nun das hier gebaut:

    https://www.autoitscript.com/forum/topic/20…ct-pure-autoit/

    Hi hi, hab gerade mal quer gelesen, da hast du ja selbst etwas entwickelt, was wahrscheinlich das weiter oben beschriebene Dictionary überflüssig macht. ;)

    Wieviel Aufwand wäre es denn, wenn du ein Minimal-Demo erstellst, mit einem Hauptscript das einen Button hat (und ein Edit*?), mit dem ein "Business Objekte" Script erzeugt werden kann? * Das Edit habe ich erwähnt, weil ich ja nicht weiß, wie die User das im echten Programm machen. - Dann sollten noch 1 - 2 Buttons drauf, die das machen bzw. nicht machen, worum es dir geht, also die Funktionen aus dem Unterscript aufrufen, ohne Prog-Neustart. Noch eine Datei hinzufügen, die den Code mit 1 - 2 Foo-Funktionen für das Unterscript enthält, den man im Edit einfügt, um das Unterscript per Button zu erstellen.

    Vielleicht hilfst das, Ideen zu entwickeln. (Vielleicht hast du das aber schon längst gemacht in deinen vorherigen Postings und ich habe es nur nicht gesehen. Dann Schande über mich!) 8|

    Wenn jemand sagt: "Das geht nicht!" Denke daran: Das sind seine Grenzen, nicht deine.

  • Hi, im Anhang findest du sehr vereinfachte Beispiele um zwischen Lua & AutoIt callbacks / daten auszutauschen. Da geht natürlich um einiges mehr. Allerdings hat mich das schreiben der lua udf einiges an zeit gekostet und sie ist bestimmt noch voller bugs (und unvollständig ^^). Zu dem AutoItObject schreibe ich dir gerne spezifisch auch noch ein Beispiel, aber das sollte dir den groben Einblick geben in wie fern du Lua einbinden könntest. Ich hab nur heute / morgen leider nicht mehr viel Zeit, daher musts du noch aufs Wochenende warten. Viel zu tun :/

    Kannst ja in der Zwischenzeit ein wenig mit dem Gedanken spielen und paar Sachen ausprobieren. Die Lua API Referenz findest du hier:

    Lua manual

    Scroll einfach runter bist du die ganze Liste mit der "C API" findest.

  • Danke für Euren Input!

    Bist du sicher, dass es sich so verhält? Meiner Vorstellung nach sollte ein ROT Objekt für alle Scripts gleich verfügbar sein. Vielleicht wird das Objekt im aktuellen Script nicht geändert (im Sinne von aktualisieren des bestehenden Objekts) sondern neu erstellt? - Bedenke, dass ich hierbei nur rate, mein Wissen reicht dafür nicht aus! :( Aber vielleicht liest ja jemand mit, der sich besser auskennt. :rock:

    Download zip: rot problem example autoitobject.zip

    Problem und Workaround noch einmal anschaulich.

    -> Example_Problem.au3 bzw. Example_Workaround.au3 starten.

    So hat mich z.B. verwundert im Zusammenhang mit ROT über Server und Client zu lesen. In meinem Fall, wo ich ein COM ROT Dictionary Objekt benutze, braucht es keinen Server in dem Sinne. Ein Standard-Objekt wird erstellt ObjCreate("Scripting.Dictionary") und im ROT registriert $oRunningObjectTable.Register($iFlags, $pObject, $pMoniker, $iHandle). Danach ist das Dictionary in allen Scripts zur Verfügung, die das "Zauberwort" kennen, also der Moniker (Name) unter dem man das Dict im ROT registriert hat.

    Guter Hinweis - ich werde mir bei Gelegenheit anschauen, wie die .Register-Methode von ausprogrammiert ist, bzw. ob man mit den Flags noch etwas machen kann - vielleicht macht das einen Unterschied.

    Wieviel Aufwand wäre es denn, wenn du ein Minimal-Demo erstellst, mit einem Hauptscript das einen Button hat (und ein Edit*?), mit dem ein "Business Objekte" Script erzeugt werden kann? * Das Edit habe ich erwähnt, weil ich ja nicht weiß, wie die User das im echten Programm machen. - Dann sollten noch 1 - 2 Buttons drauf, die das machen bzw. nicht machen, worum es dir geht, also die Funktionen aus dem Unterscript aufrufen, ohne Prog-Neustart. Noch eine Datei hinzufügen, die den Code mit 1 - 2 Foo-Funktionen für das Unterscript enthält, den man im Edit einfügt, um das Unterscript per Button zu erstellen.

    Download zip: generate objects gui.zip

    -> Zum Testen: Starten, "Add Objekt" -> beliebiger name eingeben -> "Add Method" -> beliebiger Name eingeben -> im Popup nun code einfügen - zum beispiel folgenden

    Code
    $oObjectDisplay = _BuildObject("DisplayAMessageBox")
    $oObjectDisplay.display_messageboxes()

    -> Codeeingabefenster schließen -> Methode in der Liste Rechts auswählen -> "Run Method" -> Nichts wird passieren.

    -> Programm neustarten -> Edit Objekt -> Methode auswählen -> Run Method -> wird ausgeführt werden.

    Ich hab nur heute / morgen leider nicht mehr viel Zeit, daher musts du noch aufs Wochenende warten. Viel zu tun

    Kein Problem. Das läuft nicht weg; ich bin z.Z. auch im Stress. Das Lua Beispiel muss ich mir noch ancshauen, ich melde mich dazu.

    Danke schon mal für eure antworten & input.

  • Hi, hier ein etwas besseres Beispiel. Die Lua UDF ist jetzt auch fertig (soweit). Ich schaue mir mal das Beispiel an was du da geschickt hast und schreibe dir dann jetzt ein Beispiel mit Lua integration. Ich würde mir schlichtweg wirklich überlegen, ob User Skripte nicht einfach in Lua geschrieben werden könnten. Das würde dein Vorhaben definitiv vereinfachen. Lua ist keine besonders schwere Sprache und du kannst AutoIt Funktionen für Lua Verfügbar machen (siehe Beispiel im Anhang, da hab ich die MsgBox genommen).

    Der Vorteil daran ist auch, du kannst mit deinem Hauptprogramm bestimmen auf welche Funktionalität die User überhaupt Zugriff haben. So kann keiner eine AutoIt Funktionen so einfach exploiten. Was du nicht exportierst ist auch nicht verfügbar. :P

  • Im Anhang findest du das Beispiel zu deiner GUI mit Lua. Irgendwie ist mir allerdings AutoItObject komplett rausgefallen, es war nicht ansatzweise benötigt. Zumindest für das Minimalbeispiel was du gepostet hattest. Ich hab da paar Kommentare hinterlassen.

    Die Objekte welche du in der GUI erstellst sind direkt (ohne Neustart) vorhanden. Also so ziemlich das was du wolltest, abgesehen davon dass du bisher mit AutoItObject das ganze implementiert hast. Was dir bestimmt noch auffallen dürfte ist, dass die include Datei weg ist. Tja... Nicht notwendig. x)

    Ich habe versucht dein Orginalbeispiel so weit wie möglich orginal zu lassen. Allerdings war ich am überlegen ob ich es komplett umschreibe. Die Struktur gefällt mir persönlich nicht. Aber ich denke so kannst du dich besser zurechtfinden wenn ich nur an dem nötigsten rumdockter.

    Wenn du dich für die Lua Lösung entscheidest sag bescheid. Ich helfe dir da gerne weiter. Ansonsten sehen wir uns bei der AutoIt Variante weiter um. Legacy Support zu den vorhandenen AutoItObjects könnten wir noch intigrieren. Dürfte nicht so schwer sein.

    Die Beispiele kratzen nur an der Oberfläche von dem was geht. ;)

  • Hey,

    danke für die Mühe mit dem Lua Beispiel - sieht ganz nett aus. Potential hat es auf jeden Fall - aber am Ende des Tages bin ich mir nicht sicher, ob das mit meiner Vision einhergeht. Ich behalte das im Hinterkopf.

    Wichtiger wäre mir das hier: RE: Self Modifying Code / IPC / Funktionen zur Laufzeit erzeugen

    Danke und viele Grüße

  • Wichtiger wäre mir das hier: RE: Self Modifying Code / IPC / Funktionen zur Laufzeit erzeugen

    Huh? Ich hatte doch bereits ein Beispiel geschrieben wie du auf Daten zwischen Lua + AutoIt austauscht. Und auch wie du Funktionen aufrufst. Das war's... Reicht doch aus um ein AutoItObject komplett abzudecken oder nicht? - Oder willst du mir was anderes sagen mit der Verlinkung?

  • Ich find's nett, dass Du Dir die Mühe mit den Beispielscripten machst - aber hilfreicher fände ich es, wenn die Antworten Bezug auf die Frage in dem Post nehmen würden.

    Also konkret: Der Zugriff auf das AutoItObject-Object, entweder mittels Parameter oder ROT. Ich habe nicht vor AutoItObject als Ganzes abzulösen, sehe aber nicht wie ich einen komplexen datentyp übergebe.

    Danke Dir,