Beiträge von SEuBo

  • Auf Screen gezeichnete GDI+ Grafiken wieder sauber löschen - Ohne Flackern

    Was Du vermutlich brauchst, ist ein sog. Backbuffer. Schau Dir mal ein paar Threads im Zusammenhang von AutoIt, GDI+ und Backbuffer an.

    Außerdem solltest Du die Grafik wahrscheinlich nur zu bestimmten Zeitpunkten aktualisieren. Windows stellt dafür Events (Stichwort: WM_PAINT) zur Verfügung.


    Mehr Infos gibt es z.B. hier:

    GDI+ Backbuffer verstehen - Übersicht

    https://www.autoitscript.com/f…/105866-gdi-doublebuffer/

    https://www.autoitscript.com/forum/topic/86210-gdi/


    Hier ist ein altes Beispiel von mir, als ich noch tiefer in dem Thema steckte - starten, Shift-Taste gedrückt halten und die Maus bewegen:


    Viele Grüße,

  • AutoItSimpleObjects - Objektorientierung in AutoIt

    AutoItSimpleObjects.au3

  • AutoItSimpleObjects - Objektorientierung in AutoIt

    Hallo zusammen,


    ich möchte Euch hier eine erste Version von AutoItSimpleObjects vorstellen. Das Ziel ist es, erstes Feedback zu sammeln, um zu erfahren, wohin die Reise gehen soll - also was man sich als Community unter objektorientierung in AutoIt vorstellt, welche Funktionalität man sich dabei wünscht, und wie man damit einen Mehrwert für die Sprache bringen kann. Ich finde es schade, dass AutoItObject nicht mehr weiterentwickelt wird, und AutoItObject_Internal nur Attribute, setter()- und getter()- kann. Deswegen möchte ich das Thema aufgreifen. DISCLAIMER: Alles was ich im Folgenden über AutoItSimpleObjects sage, beschreibt den aktuellen Zustand - nicht immer unbedingt das finale Ziel. Wenn ich also z.B. sage, es gibt nur öffentliche Attribute - dann heißt das nicht, dass das so bleiben muss.


    Wer noch nie von objektorientierter Programmierung gehört hat, tut sich gut daran, ggf. eine kurze Runde durch das Internet zu drehen. Starten kann man z.B. hier: https://de.wikipedia.org/wiki/Objektorientierung


    1. Was kann AutoItSimpleObjects?* (*Stand jetzt)

    AutoItSimpleObjects (kurz "ASO") ermöglicht die Erzeugung von einfachen Objekten, die Attribute und -Methoden besitzen können. Im Gegensatz zu AutoItObject werden dafür keine zusätzlichen Dateien wie z.B. DLL's benötigt.

    Die Erzeugung von Objekten, Zuweisung von Methoden oder das Anlegen von Attributen ist dabei stark an das originale AutoItObject angelehnt - Alle Attribute und Methoden sind allerdings öffentlich.

    AutoItSimpleObjects unterstützt 64-Bit und zur Not auch ByRef Parameter in Methodenaufrufen. Objekte können kopiert werden, was eine Art der Pseudo-Vererbung ermöglicht.

    AutoIt
    $oObject = _ASO_Create() ; Create Object
    AutoIt
    _ASO_AddProperty($oObject, 'test') ; Add Property
    AutoIt
    _ASO_AddMethod($oObject, 'Method1', _method1) ; Add Method


    2. Was ist AutoItSimpleObjects?

    Technisch gesehen ist AutoItSimpleObjects ein Wrapper zu AutoItObject_Internal, der mit einer eigenen Invoke-Methode und einigen wenigen Komfortfunktionen daherkommt.

    AutoItObject beinhaltet somit die gesamte Funktionialität von AutoItObject_Internal und fügt ihr folgende wesentliche Merkmale hinzu:

    • Die eigene Invoke-Methode ermöglicht den Aufruf von Methoden, die nicht __getter- oder __setter-Methoden sind.
    • Alle Objekte haben eine zusätzliche Eigentschaft "__dirty".

    Die Objekte, die in ASO erzeugt werden, sind Instanzen von IDispatch - Zugriff auf Attribute und Methodenaufrufe sind also Callbacks - deswegen sollten Methoden klein und kurz gehalten werden. (Bitte keine GUI-Messageloops in Methoden. :))


    3. Was kann AutoItSimpleObjects (noch) NICHT?

    • Vererbung
    • Klassen
    • Sichtbarkeiten
    • Interfaces


    4. Wie verwende ich AutoItSimpleObjects / Was gibt es zu beachten?

    Im nachfolgenden ein kurzes Beispiel zur Anlage eines einfachen Objekts, der Zuweisung von Attributen und der Definition von Methoden:


    AutoItSimpleObjects Example.au3


    Ansonsten kann AutoItSimpleObjects genau wie AutoItObject_Internal genutzt werden. Siehe dazu die Beispiele auf GitHub. Es gilt folgendes zu beachten:

    • Im Gegensatz zu AutoItObject benötigen Funktionen keinen zusätzlichen Parameter $oSelf als ersten Parameter der Funktion. Die Deklaration von Methoden wird dadurch einfacher.
    • Der Zugriff auf das aktuelle Objekt innerhalb einer Methode erfolgt stattdessen mittels Aufruf von $oThis = _ASO_This() am Anfang der Funktion.
    • Der Zugriff auf eine Methode $oObject.Methodname() ohne Klammern (also $oObject.Methodname) ruft die zugewiesene Funktion ohne Parameter auf, statt eine Funktionsreferenz zurückzuliefern. Das ist technisch bedingt, weil uns AutoIt nicht ermöglicht, zwischen Attributszugriff und Methodenaufruf ohne Parameter zu unterscheiden. Zeile 48 könnte also auch so lauten: $vRet = $oObject.Method3**
    • Die Nutzung von ByRef-Parametern in einem Methodenaufruf erfordert es, die Funktionsreferenz in einer separaten Variable zu speichern, siehe Zeile 30 ff. Dabei muss die Funktionsreferenz unbedingt mit $oObject.__get("Methodname") geholt werden - ein Zugriff mittels $pFunc = $oObject.Methodname führt zu einem Fehler. Siehe vorheriger Punkt.**
    • Die Methoden _ASO_AddMethod(...) und _ASO_AddProperty(...) sind eigentlich überflüssig. Attribute müssen nicht explizit angelegt werden, sondern werden bei der ersten Zuweisung automatisch Public erstellt und Methoden werden dadurch erstellt, dass einem Attribute eine Funktionsreferenz zugewiesen wird. Zeile 6-11 im oberen Beispiel können also auch wie folgt lauten:
    AutoIt
    $oObject = _ASO_Create()
$oObject.test = ""
$oObject.Method1 = __method1
$oObject.Method2_with_byref = _TestMethodByref
$oObject.Method3 = _method3


    ** dieses Verhalten lässt sich durch das setzen des __dirty-Attributs eines Objektes auf 'True' ändern; ist ein Objekt __dirty, so wird es beim Zugriff auf eine Methode die Funktionsreferenz der zugewiesenen Funktion zurückliefern, statt sie ohne Parameter aufzurufen. Das hat zur Folge, dass Methoden ohne Parameter nur mit dem AutoIt Schlüsselwort "Call" aufgerufen werden können, oder die Funktionsreferenz in einer separaten Variable gespeichert werden muss, um sie ohne Parameter aufzurufen. Auf der anderen Seite können mit gesetztem __dirty-Flag ByRef-Parameter verwendet werden, ohne die Funktionsreferenz vorher explizit in einer Variable zu speichern.


    Siehe dazu nachfolgendes Beispiel:

    AutoItSimpleObjects Example_dirty.au3


    Zu beachten ist hier noch einmal folgende Kurzschreibweise, speziell für/mit ByRef-Paremetern.

    In Zeile 1 ist ($oObject.Method2_with_byref) eingeklammert; deswege wird zuerst die Funktionsreferenz von Method2_with_byref aufgelöst. Danach wird die Funktion "normal" von AutoIt aufgerufen.

    In Zeile 2 wird die Methode über das IDispatch-Interface aufgerufen, das keine ByRef Paramter unterstützt. FYI: Ohne gesetztes __dirty-Flag würde $oObject.Method2_with_byref in Zeile 1 über IDispatch ohne Parameter aufgerufen.

    AutoIt
    $vRet = ($oObject.Method2_with_byref)($aArray, "New Value!")
$vRet = $oObject.Method2_with_byref($aArray, "doesn't work :(")


    5. Was brauche ich von Euch?

    Anwendungsfälle, Ideen, Feedback.

    Mal ins Blaue gedacht: Wofür würdet Ihr OO- benutzen? Sind Dinge wie Interfaces, Klassen, Traits, ByRef-Paramter, usw. für Euch unabdingbar bzw. was wäre Funktionalität, die Ihr nicht braucht?

    Ist die UDF einfach genug - oder zu einfach gehalten? Sind die Syntaxmöglichkeiten in AutoIt ausreichend?


    Die UDF: AutoItSimpleObjects.au3

    siehe Post #2, oder Anhang


    AutoItSimpleObjects Example.au3 / AutoItSimpleObjects Example_dirty.au3

    s.o.

  • Pfad und Dateiname aus Variablen zusammenbauen

    Zitat von kayes

    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.

    Zitat von kayes

    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)

  • Wie aktiviere mit WinHttp.au3 eine Checkbox?

    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.

  • AutoIt3Wrapper - Funktion beim Compilen ausführen

    Zitat von Professor Bernd

    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!


    Zitat von Professor Bernd

    Schlechte Nachrichten: :(

    schade!

    Zitat von Yjuq

    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.

  • Self Modifying Code / IPC / Funktionen zur Laufzeit erzeugen

    Zitat von Yjuq

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


    Zitat von Yjuq

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

  • AutoIt3Wrapper - Funktion beim Compilen ausführen

    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

  • Self Modifying Code / IPC / Funktionen zur Laufzeit erzeugen

    Hey,

    Zitat von Yjuq

    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?

    Zitat von Yjuq

    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.

    Zitat von Yjuq

    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,

  • Self Modifying Code / IPC / Funktionen zur Laufzeit erzeugen

    Zitat von Yjuq

    ??? - 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,

  • Self Modifying Code / IPC / Funktionen zur Laufzeit erzeugen

    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,

  • Self Modifying Code / IPC / Funktionen zur Laufzeit erzeugen

    Danke für Euren Input!


    Zitat von Professor Bernd

    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.

    Zitat von Professor Bernd

    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.

    Zitat von Professor Bernd

    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.

    Zitat von Yjuq

    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.

  • Self Modifying Code / IPC / Funktionen zur Laufzeit erzeugen

    Zitat von BugFix

    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:

  • Self Modifying Code / IPC / Funktionen zur Laufzeit erzeugen

    Hey,

    Zitat von Professor Bernd

    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.


    Zitat von Professor Bernd

    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.

    Zitat von Professor Bernd

    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.

    Zitat von Professor Bernd

    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!