Beiträge von SEuBo

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)

Zitat von Professor Bernd

Hi Guys. hab jetzt nur quer gelesen, ... könnte das hier helfen: "Lua Com" ?

Mit Sicherheit vielleicht. Yjuq kann das wahrscheinlich besser beurteilen

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.

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.

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.

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:

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

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

Danke und viele Grüße

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,

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,

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,

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

Kein Problem, ich war heute ja auch sehr kurz angebunden

habe versucht, es minimalistisch zu halten - wenn irgendwas unklar ist, einfach fragen.

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.

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

$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.

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.

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!

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.

#include <AutoItObject.au3>
_AutoItObject_StartUp()

$oObject_Out = _AutoItObject_Create()
_AutoItObject_RegisterObject($oObject_Out, "_AutoAndLua.SomeObject")

_AutoItObject_AddMethod($oObject_Out,"some_method", "some_function")
_AutoItObject_AddData($oObject_Out,"some_data")

$oObject_Out.some_data = Random(1,100,1)
$oObject_Out.some_method("Random Data für Lua: " & $oObject_Out.some_data)


; Integrate LUA .. <<< ?




While Sleep(100)
WEnd

Func some_function($oSelf, $vParam)
    MsgBox(0,"some_function",$vParam)
EndFunc

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!

Zitat von Yjuq

Müssen es AutoIt Skripte sein?

- Ja

Zitat von Yjuq

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.

Zitat von Yjuq

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.

Zitat von Yjuq

Müssen unbedingt COM Objekte erstellt werden?

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

Zitat von Yjuq

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.

Zitat von Yjuq

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.

Func __Application__UpdateBObjects($oSelf)
    Local $aFiles = _FileListToArray(@ScriptDir & "\Objects", "*.xml")
    ; ...
    
    For $i = 1 To $aFiles[0]
        ;...
        $oBObject = $oSelf.BObject($aFiles[$i]))
        ; ...
    Next
EndFunc   ;==>__Application__UpdateBObjects



Func __Application__BObject($oSelf, $sObjectName, $oContext = Null)
    
    ; ...
    $oObject =  $oSelf.ObjectBuilder.Build($sObjectName,  $oContext)
    
    ; ...
    
    If Not $oSelf.Database.TableExists($sObjectName) Then
        $oSelf.Database.TableCreate($sObjectName, $oObject.db_resolve_attributes())
    EndIf
    
    ; ...
    
    Return $oObject
EndFunc   ;==>__Application__Object

Func __ObjectBuilder__Build($oSelf, $sObjectName, $oContext = Null)
    ; ...
    $oObject = _AutoItObject_Create()
    
    ; ... 
    ;$oSelf.AddSystemProperties($oObject, $oObject.ObjectName) -> 
    _AutoItObject_AddProperty($oObject, "Application", $ELSCOPE_PUBLIC, $oSelf)
    _AutoItObject_AddProperty($oObject, "ObjectName",  $ELSCOPE_PUBLIC, $sObjectName)
    _AutoItObject_AddProperty($oObject, "Definition",  $ELSCOPE_PUBLIC, $oXMLDoc)
    _AutoItObject_AddProperty($oObject, "Context",     $ELSCOPE_PUBLIC, $oContext)

    ; ...
    $oSelf.AddCustomProperties($oObject, $oObject.ObjectName)
    ; ...

    IF $sParentName <> "" AND ... $oContext.ObjectName = $sParentName then 
        _AutoItObject_AddProperty($oObject, $sParentName, $ELSCOPE_PUBLIC, $oContext)
        $oSelf.AddCustomProperties($oContext, $oObject.ObjectName, 2)
    EndIf     
    ; ...
                
    $oSelf.AddCustomMethods($oObject, $oObject.ObjectName)
    $oSelf.dbObjectMethods($oObject)
    ; ...

EndFunc

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.

    ; ...
    $sFilePath   = StringFormat('.\Objects\%s', $sObjectName & '.au3')
    $sIncludeStr = StringFormat('#include "%s"', $sFilePath)
    ; ...
    
    If FileExists('.\Objects\' & $sObjectName & '.au3') 
    And Not StringInStr(FileRead('.\ObjectsCollectiveInclude.au3'), $sIncludeStr) Then 
        FileWrite('.\ObjectsCollectiveInclude.au3', $sIncludeStr & @CRLF)
        ; ...
    EndIf
            
        $oSelf.Application.Restart()

        ; ...

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.

    ; Erstelle Kontrakt mit KUNDEN als basis
    $oCustomer = $oSelf.Application.BObjects.Customer()
    $oCustomer.name     = 'Max Musterbert'
    $oCustomer.address  = 'Mustermannstr. 144,\n12345 Musterhausen'
    $oCustomer.country  = 'DE'
    
    ; Kontrakt im Kontext des Kunden erstellen
    $oContract = $oSelf.Application.BObjects.Contract($oCustomer)
    $oContract.ID       =  'DL_2021_124556'    
    
    ; Material im Kontext des Kontraktes (im Kontext des Kunden) erstellen
    $oMaterial = $oContract.Add($oSelf.Application.BObjects.Material($oContract))
    $oMaterial.number     = 900001
    $oMaterial.price      = '120,00'
    $oMaterial.text     = "Stunden vor Ort"
    $oMaterial.quantity    = 100
    
    ; Material im Kontext des Kontraktes (im Kontext des Kunden) erstellen
    $oMaterial = $oContract.Add($oSelf.Application.BObjects.Material($oContract))
    $oMaterial.number     = 900002
    $oMaterial.price      = '100,00'
    $oMaterial.text     = "Stunden Remote"
    $oMaterial.quantity = 350
    
    $oContract.Save()

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.

$iSleepTime = 500
$fDoSomething = True

; $sAutoItCode = InputBox("", "Sourcecode eingeben...")
$sAutoItCode = _AutoItCode_Execute( _
         & @LF & '' _
         & @LF & '_MyMsgBox("SleepTime:" & $iSleepTime)' _            
         & @LF & '$sText = "schlecht gelaunt."' _
         & @LF & 'If $fDoSomething = True Then' _
         & @LF & '  $sText = _MyFunction(_MyRandom(85, 95))' _
         & @LF & 'EndIf' _
         & @LF & '' _
         & @LF & 'Func _MyMsgBox($sText)' _
         & @LF & '  MsgBox(64, "", $sText)' _
         & @LF & 'EndFunc' _
         & @LF & '' _
         & @LF & 'Func _MyFunction($iThreshold)' _
         & @LF & '  For $i = 1 to 100' _
         & @LF & '    IF $i <= $iTreshold then ' _
         & @LF & '      Sleep(10)' _
         & @LF & '    Else' _
         & @LF & '      Sleep($iSleepTime) ' _
         & @LF & '    EndIf' _
         & @LF & '' _
         & @LF & '    ToolTip("Counter:" & $i)' _
         & @LF & '  Next' _ 
         & @LF & '  Return "Erfolgreich!"' _ 
         & @LF & 'EndFunc' ) 

Msgbox(0,"", "Die der Code war " & $sText)
Func _MyRandom($iFrom, $iTo)
    Return Random($iFrom, $iTo, 1)
EndFunc

Func _AutoItCode_Execute($sSourceCode)
    
    ; ... ?  
    
EndFunc

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

#include <AutoItObject.au3>
#include "AllObjects.au3"
_AutoItObject_Startup()

$oObject = _AutoItObject_Create()

; $aXMLAttributes[] = wird aus Datei gelesen, z.B. ["foo", "bar"]
$sObjectName = 'TheAlmightyObject'
For $i = 0 To UBound($aXMLAttributes) - 1
    _AutoItObject_AddProperty($oObject, $aXMLAttributes[$i])
Next

; $aXMLMethods[] = wird aus Datei gelesen, z.B. [["Funktion_1", "MessageBox(0,'','Ich bin Funktion 1 foooooo '"] , ["Funktion_2", "MessageBox(0,'','Ich bin Funktion 2 baaaaar'"]]
For $i = 0 To UBound($aXMLMethods) - 1    ; Neue Datei mit dem Funktioncoding erzeugen 
       FileWrite(@ScriptDir & '\TheAlmightyObject.au3', "Func " & $aXMLMethods[$i][0] & "()" & @LF & $aXMLMethods[$i][1] & @LF & "EndFunc") 
       _AutoItObject_AddMethod($oObject, $aXMLMethods[$i][0], "someFunctionNamePrefix" & $aXMLMethods[$i][0])
Next
FileWrite(@ScriptDir & "\AllObjects.au3", @CRLF & "#include "TheAlmightyObject.au3" )

$oObject.foo = 10 ; klappt!
$oObject.Funktion_1() ; klappt erst beim zweiten start des programms, weil TheAlmightyObject.au3 vorher nicht existierte.

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

#include <AutoItObject.au3>
_AutoItObject_Startup()

; Container für Datenübergabe, Callbacks, etc.
$oObject_In = _AutoItObject_Create()
_AutoItObject_RegisterObject($oObject_In, 'AutoItTest.SelfMody.In')
_AutoItObject_AddProperty($oObject_In, 'ready')

; Beispiel: Callback-Methode
_AutoItObject_AddMethod($oObject_In,"MessageBox", "MessageBox")
$oObject_In.MessageBox("1) Regular call of function from within the same script")

; Externe Funktion "generieren"
Make_external_function()

; Externe Funktion aufrufen:
Do    Sleep(100)
Until $oObject_In.ready

$oObject_Out = ObjGet("AutoItTest.SelfMody.Out")
$oObject_Out.some_external_function("3) call of function in external (generated) Script")

Func MessageBox($oSelf, $sText)    MsgBox(0,"",$sText)
EndFunc



Func Make_external_function()
    $sSourceCode = ''  _  
    &@LF&    '#include <AutoItObject.au3>' _   
    &@LF&    '_AutoItObject_StartUp()' _   
    &@LF&    '$oObject_In  = ObjGet("AutoItTest.SelfMody.In")' _   
    &@LF&    '' _   
    &@LF&    '$oObject_Out = _AutoItObject_Create()' _   
    &@LF&    '_AutoItObject_AddMethod($oObject_Out,"some_external_function", "some_external_function")' _   
    &@LF&    '_AutoItObject_RegisterObject($oObject_Out, "AutoItTest.SelfMody.Out")' _        &@LF&    '' _   
    &@LF&    '$oObject_In.MessageBox("2) Callback of Function from external script")' _   
    &@LF&    '$oObject_In.ready = True' _   
    &@LF&    '' _   
    &@LF&    'While Sleep(100)' _   
    &@LF&    'WEnd' _   
    &@LF&    '' _   
    &@LF&    'Func some_external_function($oSelf, $vParam)' _   
    &@LF&    '    MsgBox(0,"some_external_function",$vParam)' _   
    &@LF&    '    Exit' _   
    &@LF&    'EndFunc'
    FileDelete(@ScriptDir & '\autoitselfmody.au3')  
    FileWrite(@ScriptDir & '\autoitselfmody.au3', $sSourceCode)  
    Run(StringFormat('%s /AutoIt3ExecuteScript "%s"', @AutoItExe, @ScriptDir & '\autoitselfmody.au3'),@ScriptDir)
EndFunc

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,

Zitat von CHmux

Hallo zusammen!
Das ICU sieht schon mal klasse aus. So was in der Art hab ich gesucht.

Aber kann man auch rein als Skript ausführen?

Ich hab mir den Source heruntergeladen und da wird beim Start gleich eine

EXE-Datei erzeugt. Das ist cool für zu Hause, aber in meiner FIrma ist die

EXE nicht auf der WhiteList und damit nicht ausführbar.

Ich brauch also eine reine Skript-Lösung.

Was wäre einfacher? Das ICU auf Skript umstellen oder die Beispielskripte hier

etwas auzupeppen?

Alles anzeigen

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.

Zitat von Bitnugger

Schon seltsam... ich habe:

AutoIt: 3.3.14.5/X64

PC1: Windows 10 20H2 (Build 19042.685), X64

PC2: Windows 10 Version 2004 (Build 19041.685), X64

Auf PC1 habe ich Fences installiert ControlGetHandle("[CLASS:NDesk]", ...) und auf PC2 nicht ControlGetHandle("[CLASS:Progman]", ...), auf beiden funktioniert es.

Mein bei Windows angemeldeter User ist in der Gruppe der Administratoren (Default) und UAC ist deaktiviert... aber das kann es nicht sein!?

Was sagt denn das AutoIt-Info-Tool, wenn du den Finder auf dem Desktop (freie Stelle) loslässt?

Alles anzeigen

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.

Funktionieren allerdings beide (weder das von Veronesi, noch von Dir Bitnugger ) bei mir. Windows 10 version 2004 , 64 Bit.

Das Desktop-Handle kann nicht gefunden werden.