Beiträge von SEuBo

    2. Problem: Wie mache ich mich von der Dateiendung unabhängig.

    FileFindFirstFile/FileFindNextFile oder _FileListToArray - du suchst dann nach Dateien mit Dateiendung .* und bist so auch nicht gezwungen, alle im Universum existierenden Dateiendungen in dein Script zu tippen, oben vorgeschlagen.

    bei der 2. und 3. Eingabe muss ich eine Null vorstellen bzw. mit Nullen auffüllen. Wie kann ich bei der Eingabe von 2 auf 00002 stellen?

    Oder statt mit StringFormat, was ich immer etwas kryptisch finde, einfach mit StringRight.

    StringRight("00000" & $iZahl, 5)

    Hey,


    in's blaue hinein gesprochen: WinHTTP ist grundsätzlich erst einmal nur eine Sammlung von Funktionen, die eine direkte Kommunikation mittels HTTP Protokoll ermöglicht.

    Das heißt einfach gesagt - Du kannst mit einem Webserver sprechen, ohne einen Browser verwenden zu müssen. Das wird i.d.R. aus Performancegründen gemacht. Soweit klar.


    Wenn man mittels WinHTTP mit einem Webserver "spricht", macht man in der Regel viele der Dinge, die ein Browser automatisch macht, manuell. Das setzen von Cookies, Weiterleitung auf andere Websiten, Umschalten der Verschlüsselung, etc.


    Will man mittels WinHTTP Formularfelder auf Websiten ausfüllen, oder Checkboxen anklicken - dann teilt man das dem Webserver genau so mit, wie es ein Browser tun würde. Im Browser trägst Du alles fein säuberlich ein und drückst dann auf "Senden". Der Browser überträgt die Formulardaten dann an den Webserver. In aller Regel geschieht das im Internet mittels HTTP Post Request.


    Du wirst also folgendes machen müssen:

    Nach dem erfolgreichen Login musst du einen erneuten HTTP POST Request absetzen, der dein "Checkbox-Formular" an den Server überträgt. Um über die Daten bescheid zu wissen, die Du senden musst, kannst Du den Login im Browser ausführen und die HTTP Requests und Responses mitschneiden (Stichwort "LiveHttpHeaders"). Den entsprechenden Request musst Du in WinHTTP nachbilden.

    Sorry, keine Lösung für dein Problem, aber bei mir gibts Fehler bei F7 ohne die roten Anführungszeichen. :)


    #AutoIt3Wrapper_Run_Before=""%autoitdir%\AutoIt3.exe" "%in%" -Something"

    thx!


    Schlechte Nachrichten: :(

    schade!

    Du kannst für die SciTE eine eigene implementation für F7 schreiben. Basierend darauf kannst du eine Start-Skript generieren welche diese Anweisungen beinhaltet und deine Hauptdatei einbindet. Musst halt nur sämtliche include files für diese Anweisungen parsen und in dein Start-Skript schmeißen.


    Du kannst diese Implementation entweder in Lua schreiben oder vielleicht durch eine Mischung von AutoIt und der SciTE Config Files herbeiführen. Vielleicht auch Lua + Autoit. Musst dich wohl durch die SciTE Docu durchwühlen.

    Oder ich sage einfach, dass zusätzlich zu einer Include-Anweisung auch noch die Zeile #AutoIt3Wrapper_Run_Before=""%autoitdir%\AutoIt3.exe" "%in%" -Something" eingefügt werden muss, wenn die Leutchens zu faul sind, das Script vor dem Compilen einmal mit F5 zu starten.

    Ich war gerade dabei noch die AutoIt Objekte einzubinden, also eine einfache Funktion die dir ermöglicht auf alle deine vorhandenen AutoIt Objekte zuzugreifen.

    Das Gegenstück zu AutoIt's ObjGet() in Lua würde mir schon reichen ;)


    Vielleicht hat jemand anderes noch eine Idee? Mich wundert es sowieso warum sich hier keiner meldet. :P

    Ich denke das Problem ist, dass ,
    1) sich Threads schnell "verrennen", und Leute nicht unbedingt gewollt sind, einer ellenlangen sehr technischen Konversation zu folgen.
    2) sich Leute weniger interessieren, wenn es schon einen Workaround gibt oder im Thread schon eine mögliche Lösung vorgeschlagen wurde. (Frei nach dem Motto: "Soll er das doch irgendwie reinbasteln und fertig!".)

    3) die landläufige Meinung ist, dass es "nicht geht". AutoIt kann das nicht und Punkt. Aber die Erde war auch einmal der Mittelpunkt des Universums und alles andere war Quatsch.


    Über die Jahre habe ich einige Versuche in diese Richtung u.a. mittels Multithreading oder Injection, etc. mitbekommen, und wahrscheinlich die Hälfte der Erkenntnisse daraus wieder vergessen. Bei mir hängengeblieben, ist aber, dass es noch keiner so wirklich geschafft hat. Und das verstehe ich einfach nicht! Hier (und auch im englischen Forum) sind so viele schlaue Leute - da wird der verrückteste Scheiß gebastelt... aber keiner schafft es, den AutoIt Interpreter zu bändigen?!


    Ich finde diesen Thread hier so interessant - da sieht man was passiert, wenn man so eine Frage im Englischen Forum stellt. Der gute Busti hat alles versucht und immer wieder neue Ansätze präsentiert bis er kleingeredet wurde. https://www.autoitscript.com/f…etreive-the-struct-of-it/



    Also Leute!


    Die Frage ist und bleibt offen: Wie generiere ich (möglichst elegant) eine AutoIt-Funktion zur Laufzeit? :)

    Hallo zusammen,


    mit #AutoIt3Wrapper_Run_Before kann ich einen Befehl ausführen, bevor das Script kompilliert wird. Beispiel:

    Folgendes Script verhält sich unterschiedlich, je nachdem ob man in SciTE F5 oder F7 drückt:

    Code: startuptest.au3
    #AutoIt3Wrapper_Run_Before="%autoitdir%\AutoIt3.exe "%in%" -Something"
    #OnAutoItStartRegister "StartUpFunction"
    Func StartUpFunction()
    If StringInStr($CmdLineRaw, "-Something", 1) Then
    MsgBox(64,"","Ich mache besondere Dinge")
    Else
    MsgBox(0,"","Ganz normale Dinge.")
    EndIf
    EndFunc


    Wenn Ich nun aber das Ganze in ein Include hülle, wird #AutoIt3Wrapper_RunBefore ignoriert, und das Script macht vor dem Compilen nun gar nichts mehr. Kennt jemand dafür eine Lösung?

    Code: startupmain.au3
    #include "startuptest.au3"
    MsgBox(0,"","Programm läuft")


    Danke und viele Grüße

    Hey,

    Ja? Das ist ja der Sinn dahinter. Schau dir Post #18 nochmal an. Da wird alles direkt geladen und ist direkt global verfügbar. Wenn du ein neues Objekt in deiner GUI anlegst kannst du es auch direkt verwenden ohne Neustart. Das ganze lässt sich auf alles übertragen. Ganze Skripte können geladen und ausgeführt werden zur Laufzeit.

    Da habe ich gestern irgendwie Module und Plugins durcheinandergewürfelt und die Frage falsch gestellt, sorry. Dass alle Funktionen und Globals in der Lua Laufzeitumgebung verfügbar sind, hab ich kapiert. Wenn ich eine Funktionssammlung - also ein Lua Module/Rock - runterladen und integrieren will geht das on the fly. Coole Sache.

    Plugins (base, file, io, ...) entsprechen dann eingebauten AutoIt Funktionen? Kann ich Plugins zur Laufzeit aktualisieren/nachladen, nachdem schon Module geladen/Funktionen ausgeführt wurden?

    Versuch mal #AutoIt3Wrapper_UseX64=y davor zu packen. Da war die Lua UDF noch nicht ganz fertig und ich hatte es nur in 64 bit getestet.

    Und ich nur im 32 Bit Mode - Funktioniert, danke.

    Mir ist durchaus klar an was für ein Problem du sitzt. Eine Lua integration ist mein erster Vorschlag dafür. Es macht eigentlich genau das was du wünscht. Du kannst das auch (wie bereits gesagt) mit AutoIt und IPC umständlicher lösen. Ist halt nur mehr aufwand und vermutlich mehr Anfälliger für Fehler (wenn dir irgendwelche Prozesse abschmieren etc.)

    Dass Du mein Problem verstehst hab ich nicht bezweifelt - ich beschwer' mich ja gar nicht. Ich glaube, es fällt mir schwer den Umfang und die Vision zu beschreiben. Lua scheint ne schicke Geschichte zu sein und ich kann mir auch gut vorstellen, das in Teilen der Anwendung zu ermöglichen. Aber dann gerne als Alternative zu AutoIt (deswegen die Frage nach dem Zugriff auf die Objekte mittels RoT). Meine persönliche Vision ein geschlossenes System - alles ist eins (Die oben erwähnte Trennung in Business-Objekte und System-Objekte eigentlich auch nur temporär.) . Ein System, in einer Sprache geschrieben - mit einer Sprache erweiterbar - direktes Feedback, weil alles direkt am Bildschirm stattfindet - keine statik, alles ist polymorph und veränderbar - GUI Elemente die die Objekte repräsentieren. Am liebsten hätte ich die Programmiersprache Self - in abgespeckt und ein ganz klein bisschen anders, und simpler - einfach zu verstehen und nutzen im Büro/Enterprise-Kontext. Mit moderner GUI.


    Lua kann das mit Sicherheit auch alles leisten - und wäre einerseits für simple Aufgaben wie Datentransformationen einfach genug um von einem Key User getippt zu werden - aber auch mächtig genug um das ganze GUI Handling, IPC, Printing, Datenbank, Filehandling zu erledigen. Alles cool. Ich bin mit den Services und der Laufzeitumgebung meiner Applikation aber schon weit fortgeschritten und am Point of no Return vorbei - alles noch einmal auf Lua umzubauen, ist Budgettechnisch nicht mehr drin und würde auch die weitere Entwicklung verlangsamen. Da fehlt dann einiges an Routine um flott zu coden - 12 Jahre Erfahrung krieg' ich in Lua demnächst nicht mehr Zusammen. Zeittechnisch fällt das also auch weg; ich habe bestimmte Ziele die ich einhalten muss. Deswegen ist es AutoIt und bleibt es AutoIt als "first language". Der im ersten Post beschriebene Workaround funktioniert für ja mich auch - die Objekte mit neuen/geänderten Methoden werden in Worker ausgelagert bis die Applikation neu startet. Zugriff auf alle Daten der Applikation gibts quasi automatisch da alles in einem Applikation Objekt liegt, das ich einfach mittels Parameter übergeben kann. Es ist im Prinzip nur die Frage der Eleganz, die ich im ersten Post stelle.


    Übrigens: Wenn ich nicht ausgiebig Antworte, ist das nicht als unhöflich zu verstehen - ich bin wie oben gesagt dankbar für den Hinweis und die Arbeit mit den Lua Scripten - ich versuche aber aus o.g. Gründen bewusst den Thread in eine bestimmte Richtung zu lenken. - und die Richtung ist AutoIt. ;) Ich passe auch noch einmal den Titel und ersten Post an, damit der Hinweis auf AutoIt klarer wird.


    Cheers,

    ??? - Ich hab bereits alles beschrieben. Eigentlich waren die ersten Beispielskripte dafür gedacht. Aber okey... Ich schreib dir noch ein Beispiel. <.<

    Du brauchst nicht genervt zu sein. Das sorgt nicht unbedingt für eine gute Gesprächsgrundlage.


    Vielleicht sehe ich es nicht. Ich spreche von den Files in RE: Self Modifying Code / IPC / Funktionen zur Laufzeit erzeugen


    Dein erstes Beispiel ruft nur eine simple Lua Funktion auf,

    Dein zweites Besipiel schiebt ein Int in die Lua Welt,

    Dein drittes Beispiel endet in einem Programmabbruch.


    Kann ich Plugins zur Lua-Laufzeit nachladen? - Also im AutoIt-Kontext gesprochen (wo es nicht möglich ist): eine UDF herunterladen, ins Scriptverzeichnis einfügen, und während das Programm schon läuft Includen?

    Danke,

    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,

    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.

    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:

    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/f…autoitobject-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!

    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.


    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,

    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.

    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.


    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.


    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.


    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

    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 :)



    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,

    Hi,


    Funktioniert bei mir auch als Script. Wenn ich mir auf funk.eu das ICU - v6 - Source herunterlade, bekomme ich ein Archiv mit 3 Files.

    • Entpacken
    • "ICU - Icon Configuration Utility v6.au3" in Scite öffnen, Ausführen
    • (Alternativ: "ICU - Icon Configuration Utility v6.au3" mittels Drag'n'Drop im Explorer auf die "AutoIt3_x64.exe" im AutoIt-Installationsverzeichnis ziehen, etc.)
    • "Nein" bei der Frage nach der Kontextmenüintegration wählen
    • "Save" drücken, Namen eingeben, speichern.
    • DesktopIcons verschieben
    • Zu späterem Zeitpunkt das erstellte Layout wählen, "Restore" drücken.

    Nur noch der Vollständigkeit halber, um die Frage zu beantworten - Autoit (3.3.14.5), Windows 10 Version 2004 (Build 19041.685), x64 Bit. Autoit läuft in x86 Umgebung (Legacy Mode). Benutzer hat eingeschränkte Rechte, UAC ist aktiv. Mein Desktop hat die Klasse "WorkerW". Im ICU Tool scheint das berücksichtigt zu sein.