Nachtrag -> es scheint wohl einige Möglichkeiten zu geben, ob sie funktionieren, und wenn ja wie gut, teste ich mal aus.
https://www.autoitscript.com/forum/topic/20…e-autoitobject/
Beiträge von uuchip
-
-
@AspirinJunkie
Klare Antwort, Danke sehr! -
Nun nur mit Einschränkungen.
Du kannst Code aus Strings oder Dateien ausführen lassen aber da gibt es ein paar Einschränkungen.
Methode 1 - Execute():hierbei kann kurzer Code in Strings ausgeführt werden und deren Rückgabewert im Hauptskript weiterverwendet werden.
Mehrzeilige Konstrukte wie Schleifen oder Funktionsdefinitionen gehen damit nicht.
Auch Variablenzuweisungen klappen nicht.
Variablen aus dem Hauptskript können zwar in diesen Ausdrücken verwendet, aber nicht überschrieben werden - nur der Return-Wert von Execute() könnte hierfür dienen.Methode 2 - /AutoIt3ExecuteLine bzw. /AutoIt3ExecuteScript:
Man kann den AutoIt-Interpreter aufrufen und entweder eine Codezeile oder ein ganzes Skript angeben, welches ausgeführt werden soll.
Das geht auch mit der kompilierten Exe-Datei des Hauptskriptes, wenn es mit der richtigen Compileroption kompiliert wurde.
Damit kann man auch umfangreichere Skripte ausführen, aber diese haben keine Verknüpfung zum Hauptskript - teilen sich also keine Variablen usw.
Es wird einfach nur aufgerufen:AutoIt
Alles anzeigen#pragma compile(AutoItExecuteAllowed, True) ; je nachdem ob Skript kompiliert vorliegt oder direkt über den Interpreter aufgerufen wird $sAutoItExe = @Compiled ? @ScriptFullPath : @AutoItExe ; einzelne Zeile Code ausführen: $sVar = "msgbox(0,'','Test')" ; AutoIt-Code, welcher irgendwie in eine Variable gelangt ist RunWait(StringFormat('"%s" /AutoIt3ExecuteLine "%s"', $sAutoItExe, $sVar)) ; ein anderes AutoIt-Skript aufrufen, welches noch nicht kompiliert vorliegt RunWait(StringFormat('"%s" /AutoIt3ExecuteScript "%s"', $sAutoItExe, @ScriptDir & "\other.au3"))
Das erste nutze ich schon im Kontext mit Assign() um via Maps->JSON->Maps dynamisch Variablen zuzuweisen, und das klappt wunderbar. Beim zweiten bin ich mit nicht ganz sicher, darum mein evtl. doofe Nachfrage, ob wenn man ein Skript mit AutoIt3ExecuteScript() aufruft, dessen Funktionen nach dem Aufruf im "Hauptprogramm" zur Verfügung stehen?
-
Hallo in die Runde,
nachdem das mit dem verpacken von Maps in JSON so gut geklappt hat,stelle ich mir die Frage ob man auch selbst gebastelte AU3 Funktionen darin ablegen könnte?
Was ja kein Problem darstellt, aber wie lasse ich z.B. die Zeichenkette wo eine Funktion definiert würde, zur Laufzeit interpretieren, so das diese aufgerufen werden könnte?
Mit konstruktiven Grüßen -
Ich finde die 50s aber schon ziemlich heftig.
Die sind meiner Meinung nach auch viel zu lange.
Ob das am Zugriff über Wine liegt - keine Ahnung.
Aber eine Antwort auf meine Frage ob du die aktuelle Version von AutoIt verwendest steht noch aus.WINE is not Windows, und mit einer Hardware von 2008 da passt das schon. Und ja, man muss ja wenn man die maps nutzt die neuste Version von AU3 nutzen, sonst kommt man wahrscheinlich in Teufelsküche.
OT: Seite dem Ende von Windows 7 nutze ich fast konsequent Linux, und vermisse außer autoit in dieser Welt eigentlich nichts. Oder anderes herum gesagt, autoit wäre wenn ich es in Verbindung mit .NET nutzen würde, eigentlich der Grund bei Windows zu bleiben. -
AspirinJunkie Hallo nochmal, nach stundenlangem suchen ist es mir gelungen die Ursache auf meinem System zu finden, und zwar war in einer selbstgefrickelten uralt UDF.
AutoItSetOption ( "ExpandEnvStrings", 1)
gesetzt, was bei mir augenscheinlich dafür sorgt, dass das Deine UDF SEHR langsam wird. Wenn man das heraus nimmt läuft es.
Nun braucht es unter WINE auf dem alten PC ca. 50sec. statt 8160sec., und unter Windoof 10 auf einem mittelalten I7 3,7sec.
Damit kann ich leben, und bedanke mich für Deine Hilfe und das sehr brauchbare JSON UDF! -
Ich glaube ich habe die Fehler zumindest so eingekreist nämlich, dass es ein meinen UDFs liegt. Wenn ich alle meine UDFs +JSON.au3 einbinde dann läuft es in 8160sec durch, und wenn nur Deine JSON UDF geladen wird dann dauert es für mich akzeptable 50sec. So Seiteneffekte hatte ich noch nie in AU3, zumal es keine Fehlermeldung gibt, die man erwarten würde, wenn dich die UDFs irgendwie in die Quere kämen.
Mir erscheint es sinnvoll die UDFs auszublenden die ich nicht brauche, aber doof ist es schon weil alles Einbinden ist schon viel bequemer.
AutoIt
Alles anzeigen#Region ;**** Directives created by AutoIt3Wrapper_GUI **** #AutoIt3Wrapper_Compression=4 #AutoIt3Wrapper_UseUpx=y #AutoIt3Wrapper_Run_AU3Check=y #AutoIt3Wrapper_Run_Au3Stripper=y #EndRegion ;**** Directives created by AutoIt3Wrapper_GUI **** #AutoItSetOption("ExpandVarStrings",1) ;#include-once ;#include "O:\archiv\prg\prg\programmieren\sprachen\AutoIt\Include\__ALL00.au3" #AutoItSetOption("ExpandVarStrings",1) ;#include-once ;#include "O:\archiv\prg\prg\programmieren\sprachen\AutoIt\Include\__ALL00.au3" ; Lauf-Zeit 8160sec #include-once #include "O:\archiv\prg\prg\programmieren\sprachen\AutoIt\Include\JSON.au3" ; Lauf-Zeit 50sec. Func Ini() ConsoleWrite("> Ini Daten"&@CRLF) Global $jfile = "O:\archiv\prg\prg\walkowiak\DMA\dm2\vergleich012JSON\Rubber.json" ConsoleWrite("> Lese "&$jfile&@CRLF) local $InPut = FileRead($jfile) Global $JsonIn = _JSON_Parse($InPut) EndFunc Ini() Exit
-
Ich kann dein Problem nicht reproduzieren.
Die angehangene Datei "Rubber.json" wird bei mir in 1,6s eingelesen.
Um das offensichtlich bei dir vorhandene Problem zu ergründen benötigen wir nun ein Minimalskript, welches das von dir beschriebene Verhalten reproduziert (nein - das bisher gepostete ist kein Minimalskript - es sind nur 2 Funktionen), sowie die tatsächlichen Daten mit der das Problem auftritt.
Dass du die aktuelle Version der UDF verwendest, setze ich mal als gegeben voraus.Meine Konfiguration hier ist was exotisch, gelinde gesagt. Ich arbeite unter Ubuntu 20 LTS und der neusten stabilen WINE Ausführungsschicht, auf einem alten Dualcore-PC (4GB RAM und 3,6Ghz). Ich merke aber oft kaum bis wenig Performance Verluste bei AU3 Scripten zu modernen Maschinen unter Windows 10/11.
Trotzdem danke für den Hinweis, sehr wahrscheinlich liegt es nicht am UDF sondern irgendwo anderes. Nach der Programmierung eines Minimalen-Skript läuft es ca. 57sec., was erträglich ist.
-
Hallo in die Runde,
ich nutze das m.E. sehr wertvolle JSON UDF von AspirinJunkie um eine strukturell umfangreiche verschachtelte Mapstruktur zu verarbeiten. Vom Datenumfang ist die Struktur eher nicht groß, siehe "zip" - Anhang.
Das Erzeugen derselbigen ist von der Zeit hier noch erträglich, aber beim Einlesen in ein anderes Skript rechnet er sich einen Wolf. Ich habe es nach ca. einer halben Stunde angebrochen, weil es so nicht praktikabel ist für mich.
Gibt es Ideen das zu beschleunigen? Es wäre schade wenn ich wieder auf ein Gefrikel über das Dateisystem und viele CSV-Dateien zurück kehren müsste, weil vom Prinzip her sind die AU3 maps in Verbindung mit JSON schon genial.
Beste Grüße
-
@AspirinJunkie Bedanke mich herzlich!
-
@Kanashius Hallo, dass das sinnvolle ein/ auslesen von RAM-Speicher nicht einfach ist, habe ich mir schon gedacht. Immerhin scheint es auf github eine UDF zu geben, die das bei den einfachen Datentypen hinbekommt, und augenscheinlich auch bei anderen Prozessen?!
Die UDF heißt "demem.au3", und ich bin mir nicht sicher, ob es im Sinne des "Erfinders" ist, wenn man scheinbar anderen Prozessen Werte zuschustern kann?
-
Guten Morgen, ich habe gerade mal Dein JSON UDF ausprobiert, von meiner Seite aus ziehe ich den Hut!
Für mein spezielles Problem funktioniert es auch grundsätzlich, aber leider gibt es eine kleine Differenz in den Daten, oder ich mache was falsch.
In dem beigefügten Code-Schnipsel müsste eigentlich $B = $A sein, aber die Quelle $A ist ein 2D Array, und B besteht scheinbar aus 2x 1D Array, bzw. _ArrayDisplay kann $B nicht richtig auflösen/ darstellen.
AutoIt
Alles anzeigen#include <JSON.au3> #include <Array.au3> Dim $A[2][2] = [[1,2],[3,4]] Dim $M[] $M["A"] = $A $M["S"] = "Hallo Welt" $M1 = $M $M["M"] = $M1 FileWrite("mtest.json", _JSON_GenerateCompact($M)) Dim $M2[] $InPut = FileReadLine("mtest.json") ;ConsoleWrite($InPut) ;Exit $M2 = _JSON_Parse($InPut) $B = $M2["A"] _ArrayDisplay($A) _ArrayDisplay($B)
-
Nur mal so am Rande, direktes aus und einlesen von Speicherbereichen (mein erster Gedanke) scheint verpönt, weil man damit wohl auch Cheat-Bots bauen können soll. Ich möchte ausdrücklich mich davon distanzieren!
-
@AspirinJunkie
Sorry für das Missverständnis! ich wusste nicht das diese Funktionen so mächtig sind, weil ich noch nie damit gearbeitet habe. ich dachte fälschlich man müsste die ganze Struktur selber aufdrösseln.
Ich denke mein Problem ist damit gelöst, und bedanke mich herzlich für die Infos! -
AspirinJunkie Herzlichen Dank für die kompetente Antwort, man merkt das Du vom Fach bist!
Der beschriebene Weg ist wahrscheinlich der von Profis! Ich als reiner Anwedungsprogrammierer von technischen Berechnungen, die nur einmalig von mir benötigt werden, quasi als "Wegwerfskripte", programmiert mit dem m.E. Schweizer-Taschenmesser unter den Programmiersprachen, bin da viel mehr als "Bastler" unterwegs.
Z.B. die Lösung zum Ein und Auslesen von 2D Arrays aus einer Map, läuft über CSV-Dateien, deren Dateiname der Schlüsselwert ist. Das funktioniert aber nur mit wenig Aufwand, wenn die Struktur homogen ist.
Ich denke jetzt evtl. zu naiv, und weil ich keine Schnittstelle zu anderen Sprachen benötige, dass man die Map im Speicher lokalisieren könnte, und diese Daten dann in einem binären Format abspeichert, und später wieder einlesen kann? -
Hallo und guten Morgen,
ich halte denn recht neue Type MAPs für sehr hilfreich und mächtig in der Anwendung. Darum stellt sich mir die Frage ob man eine auch "nicht triviale" MAP, aus dem Speicher direkt auf den Massenspeicher schreiben und wieder einlesen kann?
Für mich bestehen "nicht triviale" MAPs aus Werten die wieder beliebigen Datentypen angehören können. Z.B. speichere ich in MAPs in einer speziellen Anwendung beliebige Array.
Vielen Dank, und beste Grüße
uuchip -
Besser?
- Was sind die Kriterien für besser, wenn etwas funktioniert?
Moderner?
- Modern heisst Zeitgeist, also etwas, was nicht funktionell ist sondern vorrangig schön anzuschauen ist.
Hab mal kurz reingeschaut. zumindest dem Manual ist nicht zu entnehmen, dass ein anderes Interface als das Einlesen von Dateien existiert. Und der große Vorteil ist ja gerade die Verarbeitung von Dateien, völlig egal von welchem Programm diese kommen.
Besser meine ich von der Funktion her, also wenn es so wie ein COM Objekt funktionieren würde wäre es m.E. am funktionalsten. Das zweitbeste wären diese Pipes die in beide Richtungen funktionieren, drittbeste eine pseudo TCP Verbindung via localhost, und an letzter Stelle käme dieses statische File was man vorher erzeugt und dann eben an gnuplot schickt. Diese Wertung gilt nur, wenn der Anwender mit Gnuplot via Autoit direkt interagieren können soll, bei Batchläufen ist es egal. Allgemein ist es m.E. so das gnuplot klein kompakt und sehr Leistsungsfähig ist. Die EXE ist kleiner 10Mb und es kann eigentlich alles was man so braucht.
-
Hallo und guten Morgen,
kennt jemand ein direktes Autoit Interface zu Gnuplot? Eine recht plumpe Lösung besteht darin, ein dummy- file mit AutoIt zu erzeugen, und dieses dann mit "run gnuplot" auszuführen. Besser und moderner wäre allerdings eine DLL-Anbindung oder eine pipe nach Gnuplot.
Vielen Dank und VG
Lutz
P.S.: An einem alternativen 2D/3D Plotter der ähnlich mächtig ist wie gnuplot, allerdings mit besserer Anbindung an Autoit, habe ich auch Interesse. Eine native AutoIt Lösung wäre perfekt, aber alles was ich bisher gesehen habe kommt leider an gnuplot nicht heran. -
Das Problem ist durch, es funktioniert, d.h. alle relevanten Daten sind in einem Array und können leicht als CSV ausgeben werden! Herrzlichen Dank für die Hilfe und die Tipps! VG Lutz
-
Prüfe als was es zurückgegeben wird:
IsArray() - AutoIt-Array
IsObj() - Ein Objekt, kann eine Liste, ein Objekt-Array sein oder ein Objekt von Objekten - kannst du meist mit For $element In durchgehen.
Schon gemacht ist läuft wie geschmiert, und an AutoIt liegt es nicht, dass ich zur Zeit die Daten nicht interpretieren kann. Ist schon doof wenn man einen Wert erwartet und die Methode 3200 Werte zurück gibt. Objektiv betrachtet funktioniert AutoIt m.E. hier richtig gut.