ScriptEngine II (v. 0.6.1)

[littleDave]

Hallo liebe DP'ler

ScriptEngineII

ist der Nachfolger meiner letzten ScriptEngine. Da es sich um ein komplettes Remake handelt, sind die beiden jedoch nicht mehr vergleichbar.

Kurzübersicht

• Die Script-Engine bnutzt Object-Pascal als Script-Sprache und unterstützt objekt-orientierte Programmierung.
• Der Quelltext wird in ByteCode übersetzt, der dann von einer optimierten RunTime ausgeführt wird
• Trotz der Möglichkeiten ist das Interface der Komponente sehr klein und übersichtlich gehalten
• Für den Einstieg habe ich eine kleine Doku in Form eines PDFs mit in den Download gepackt

Installation
In der ZIP-Datei befindet sich ein Unterordner "src". Diesen extrahiert ihr einfach in einen Ordner eurer Wahl und fügt diesen Ordner dann in den Bibliothekspfad von Delphi hinzu. Im Quelltextorder befindet sich die Datei "ScriptEngine.inc". Diese Datei kann zum konfigurieren der ScriptEngine benutzt werden. Die einzelnen Defines sind (hoffentlich) ausreichend erklärt.

Benötigte Delphi-Version
Bisher hab ich es nur mit Delphi 7 und mit Lazarus getestet. Unter FreePascal hab ich nur ein paar Tests ausgeführt und diese sind auch korrekt gelaufen. Unter Delphi 2009/2010 hab ich die ScriptEngine ebenfalls erfolgreich getestet.

Besonderheiten

• wenn man innerhalb einer Klassenmethode auf andere Klassenmethoden oder -Variablen zugreifen will, muss man immer "Self" mit angeben
  Update 10.10.2010
  Mit der Version ist 0.5.4.1 ist das nun nicht mehr notwendig!
• Records sind Referenz-Typen

Bisherige Probleme
Im Moment sind noch folgende Probleme vorhanden:

• überladene Methoden haben bisher folgende Einschränkung:
  • sie müssen alle vom selben Typ sein (statisch, nicht statisch)
• der Befehl reintroduce ist noch nicht vorhanden

Lizenz
MPL v1.1 , GPL v3.0 oder LGPL v3.0

Feature-Liste

• Übersicht
  • Object-Pascal als Dialekt
  • Ganzzahltypen: byte, shortint, word, smallint, cardinal, integer, int64
  • Fließkommatypen: single, double
  • Stringtypen: string, UTF8String, WideString
  • Operatoren: + - * / div mod shr shl and or xor not @
  • Vergleich: = < > <= >= <> is
  • Schleifen: for while repeat for-in-do
  • Datenvergleich: if case
  • Spezielle Blocks: try-finally / try-except
  • Konstanten
  • verschachtelte Unit-Namen (z.B. Unit1.SubUnit.SubUnit)
  • Partielle Units
  • Ablaufkontrolle: continue break exit
  • Exception-Handling und Exception-Throw möglich
  • Multi-Threading-Scripts
• Methoden
  • Methodentypen: procedure function constructor destructor
  • Methodenparametertypen: const var
  • Methodenoperatoren: virtual abstract override overload forward
  • Import von DLL-Methoden direkt im Script (z.B.: procedure Sleep(milliSec: DWORD); external 'kernel32.dll' name 'Sleep'; stdcall; )
  • OOP-Features: inherited
  • Spezielle Operatoren: external export
  • Unterstützte Aufrufkonventionen: register pascal stdcall cdecl
  • Methoden-Pointer
  • Events
• Records
  • Abschnitte: private protected public
  • Record-Constanten (const-Deklaration in der record-Deklaration)
  • (statische) Record-Methoden
  • (statische) Record-Variablen
  • (statische) Record-Properties
  • Property-Typen: read+write, read-only, write-only
  • Property-Zugriff: direkt, über Methoden, über Methoden mit Parametern
• Klassen
  • Objekt-Orientierte Programmierung
  • Klassenvererbung
  • Methoden überschreiben
  • Klassen-Sektionen: private protected public
  • Class-Constanten (const-Deklaration in der Class-Deklaration)
  • (statische) Klassenmethoden
  • (statische) Klassenvariablen
  • (statische) Klassenproperties
  • Property-Typen: read+write, read-only, write-only
  • Property-Zugriff: direkt, über Methoden, über Methoden mit Parametern
  • Partielle Klassen (so ähnlich wie bei .NET)
• Class Helpers
  • Es können zu jedem Datentyp beliebig viele "Helfer-Klassen" erstellt werden
  • gleicher Aufbau wie bei normalen Klassen, nur die Deklaration ist etwas anders:
    • TStringHelper = helper for string
  • Class Helpers erweitern eine Klasse/einen Datentyp ohne die Vererbung zu nutzen
• Compiler
  • schneller Compiler
  • eingebauter Unit-Cache für schnelleres kompilieren (so wie Delphi-DCUs)
  • partielle Units – mehrere einzelne Units mit gleichem Namen werden zu einer Unit zusammengefasst
  • Linker zum zusammenstellen und zum optimieren des Byte-Codes
  • IntelliSense / Code-Completion und Parameter-Hints-Unterstützung
  • eingebaut als abstrakte Klasse – für SynEdit bereits vorhanden
  • Speichern des kompilierten ByteCodes in einen Stream
• RunTime
  • schneller ByteCode-Interpreter
  • direkter Aufruf von Delphi-Funktionen
  • Script-Methoden aus dem Programm heraus aufrufbar
  • Script-Methoden als TMethod-Event nativ aufrufbar
  • einfacher Garbage Collector für Script-Klassen (nur falls das Objekt nicht manuell zerstört wurde)
  • eigener Memory-Manager mit Caching für schnelleres Ausführen und für weniger Speicherfragmentierung
  • Exception-Handling
  • Stack-Tracing
• Quelltext
  • durchgehende Namenskonvention (Units starten mit uSE2 und Klassen mit TSE2)
  • bisher keine Memory-Leaks gefunden

Noch ein paar kurze Hinweise
- Diesmal habe ich leider nicht so viele Beispiele mit in den Download hinein gepackt - es werden aber noch ein paar nachgeliefert

SVN
Ich hab für die Script-Engine ein Source-Forge-Projekt erstellt. Dort sind alle Änderungen auch per SVN abrufbar. Wichtige Releases werd ich natürlich weiterhin hier hochladen

Mitgelieferte IDE
Ich habe die kompilierte Version meiner aktuellen IDE mit in das Download-Paket gepackt. Zusätzlich hab ich den Source in den Unterordner IDEsrc gepackt - zusammen mit den drei kompilierten Packages. Mit der IDE kann man ein paar Testprojekte öffnen, die sich im Unterordner "Projects" befinden.

Ich hoffe, euch gefällt die neue Script-Engine und vielleicht kann der eine oder andere sie ja benutzen.

Download
Auf SourceForge.net (ca. 2,6 MB)

Grüße

[littleDave]

Mal wieder ein neues Update Version 0.4.1.0

Änderungen

• kleiner Bug in "Convert.IntToStr" behoben: ScriptEngine hat int64 als Parameter erwartet, nativ war aber nur ein integer angegeben
• Compiler überprüft jetzt die Unitnamen
• Compiler zeigt jetzt, wieviel Zeilen Quelltext er kompiliert hat
• Neu: Funktionspointer + Events
  Man kann jetzt entweder im Script selber eigene Events den Klassen hinzufügen (TNotifyEvent ist bereits vorhanden) oder direkt im Script Script-Funktionen (bzw. Klassen-Methoden) an Events von externen Klassen binden.

Ich weiß, das manche schon sehnsüchtig auf den Quelltext der IDE warten - ich verspreche, dass die den bis spätestens nächste Woche Montag veröffentlicht habe - um mir selbst etwas Druck zu machen

Grüße

[EugenB]

So dieser Montag ist gekommen. Wo ist der Quellcode *druck mach* hehe

Solangsam gefällt mir die ScriptEngine die helper klassen und vorallem OOP

Nicht mehr lange und ich habe alles Notwendige Importiert, um zB Forms, TCustomControl, TCanvas usw nutzen zu können , Dann nurnoch hoffen das der Import auch richtig funktioniert wie er soll

Weiter so mit der guten Arbeit

MfG,
Eugen

[olee]

Ich wollte dein nettes Programm runterladen, aber der GFI Webmanager der bei uns läuft meldet eine Bedrohung in deinem Archiv und blockt es deswegen.

Zitat:

GFI WebMonitor 4 Secure Download
--------------------------------------------------------------
Downloading: http://www.delphipraxis.net/download.php?id=40712
Filename:SEII (v. 0.4.1.0).zip

Downloading file . . . . . . . . . . success
Size: 1.714 MB.
Scanning with BitDefender . . success
(2009-10-24 14:02)
Scanning with Kaspersky . . . threat detected
(2009-10-24 12:40)
Scanning with Norman . . . . . success
(2009-10-23 18:13)

Result:
Threat detected!
Scanned with Bitdefender Scanned with Norman Kaspersky: AV Engine failure.

Kannst du das bitte mal überprüfen?

MFG

[littleDave]

Lange ists seit dem letzen Update her

Zitat von olee:

Ich wollte dein nettes Programm runterladen, aber der GFI Webmanager der bei uns läuft meldet eine Bedrohung in deinem Archiv und blockt es deswegen.

...

Kannst du das bitte mal überprüfen?

Ich hab die exe per UPX gepackt damit der Download nicht so groß ist - aber anscheinend kapieren manche AntiViren-Hersteller noch nicht, dass das nicht automatisch böse ist . Ich habs mit dem heutigen Update geändert und habe ein nicht-komprimierte exe mit hinein gesetzt.

Endlich wieder ein neues Update Version 0.4.2.0

Nach einer etwas längeren Pause hab ich mal wieder eine neue Version hochgeladen. Dank EugenB's PM-Hilfe hab ich ein paar Punkte lösen können:

• Unter FPC konnte man keine Script-Events zuweisen, da FPC eine etwas andere Call-Convetion als Delphi hat. Dies hab ich nun behoben und es sollte nun auch unter FPC möglich sein, Scriptmethoden aus der Script-Engine heraus an externe Objekte zu binden.
• Bei Event-Typen haben die Helper-Klassen nicht funktioniert
• Im Linker gab es einen Bug bei einer Namesüberprüfung - die war nämlich case-sensitive und nicht case-insensitive.

Zudem hab ich nun endlich den Quelltext sowie den Quelltext der Packages mit in das Download-Packet gepackt.

Der Download ist wie immer im ersten Post (und SVN ist eh schon up-to-date)

[EugenB]

Moin

Ich freue mich das diese Bugs gefixt wurden, hatte jedoch noch keine zeit diese zu testen.

Da ich seit Samstag Windows 64 Bit benutze konnte ich SEII unter FPC bisher nicht lauffähig "machen".

Es sind 2 Fehler (vllt sogar mehr aber kamn nur bis zum zweiten^^) nur bei den Assembler funktionen:

- Wechseln von EBP, ESP auf R*; Funktioniert nach paar Recherchen -> lässt sich Compilieren bis ->
- PutOnFPUStackExtended (gibt es vllt eine andere lösung als dieses FLD zu nutzen?)

Da ich von Assembler generell kaum was verstehe (und nie verstehen werde^^) konnte ich da nur das erste Problem lösen.

Werde mir aber so schnell wie möglich Lazarus auf 32Bit umstellen damit ich dann auch endlich mal die Events & Packages testen kann .

Mal sehen wie lange es dauert bis man die IDE & Packages auch unter FPC kompilieren kann (falls es noch nicht funtkioniert)

MfG,
Eugen

[EugenB]

Soo, habe mir jez die 32Bit Lazarus auf 64Bit Windows installiert, nun kann ich auch ganz normal wieder kompilieren

Die Packages habe soweit auch ganz einfach Konvertiert, soll ich die Patches dir zuschicken? Das selbe für die Samples? damit man nicht immer wieder die Samples neu per hand konvertieren muss ^^

Zu dem bei der IDE kann man diese leider nicht komplett auf Lazarus laufen lassen da zB TSynCompletionProposal (müsste die klasse sein) es bei Lazarus nicht gibt, ich wollte diese mal implementieren =D aber dazu hab ich zuwenig SynEdit erfahrung =D

Vllt eine IDE erstellen die für Delphi als auch für Lazarus (vom Quelltext her) funktionieren würde?

Mhm hätte da noch ne Frage zu den Packages, laut dem Quellcode der IDE werden alle Packages einmal am Start geladen, könnte man es nicht so machen das man die Packages erst lädt wenn diese im Script benötigt werden?

Ich hoffe ich habe mal am Wochenende Zeit mal mehr mit SEII zu arbeiten und zB auch die LCL Sachen als Packages zu konvertieren

Die Events muss ich noch testen. (TODO)^^

Btw, wie wäre es wenn man die Convert-Klasse fast genauso wie in .Net macht ^^ Convert.ToString() welche dann fast für alle Typen den String dazu ausgibt und das selbe für Int, Double usw

Btw 2nd, es fehlt eigentlich nur Arrays OBWOHL man kann ja auch einfach zB TIntegerList nutzen, also wäre es dann nicht vllt besser einfach anstatt arrays im script zu implementieren die Listen nutzen?

So das man bei so einer Variable

X : Array[0..12] of Integer

auch sowas nutzen könnte

X.IndexOf ; X.Add ; X.Delete usw

PS.: So langsam bräuchte ich zugriff aufs SVN und ggf deine email =D
PPS.: Wie wäre es wenn du SEII mal im Lazarus-Forum und/oder in der Mailliste präsentierst?^^ Dann würden diese bestimmt auch viele Nutzen ggf bei einigen Problemen helfen
PPPS.: Mach weiter so, diese Script Engine stellt so langsam alle anderen in den Schatten -> Ich glaub ich sollte mal ne Übersicht machen, =D habe solangsam so viele Script Engines ausprobiert mit Lazarus =D

So und nun gute Nacht =D,
Eugen

[EugenB]

Hoi

nurzur Info, Plugins die man Lazarus mit MODE DELPHI kompiliert laufen auch bei der vorkompilierten IDE

Dave ist wohl wieder sehr beschäftigt ^^.

Mal sehen ob auch eigene Plugins laufen. *test*

MfG,
Eugen

[EugenB]

Zitat von EugenB:

Hoi

nurzur Info, Plugins die man Lazarus mit MODE DELPHI kompiliert laufen auch bei der vorkompilierten IDE

Dave ist wohl wieder sehr beschäftigt ^^.

Mal sehen ob auch eigene Plugins laufen. *test*

MfG,
Eugen

Zufrüh gefreut....


Die Plugins die man mit Lazarus Kompiliert egal ob mit "{$MODE DELPHI}" oder "{$MODE OBJFPC}{$H+}" funktionieren sowohl in der vorkompilierten IDE als auch bei selbst erstellten Programmen nicht.

Folgende Meldung versuche ich schon seit Tagen zu beseitigen:

Code:

Error: [Streams] [Line 14]: Unexpected end of file
Error: [Streams] [Line 0]: Could not compile the unit "Streams"
Error: [Collections] [Line 6]: Could not add the unit "Streams"
Error: [Collections] [Line 0]: Could not compile the unit "Collections"

Wenn ich mir jetzt diese Streams angucke, wie sie in der IDE aussieht, sehe ich kein "Unexpected end of file", alle Quellcodes sind normal angezeigt.

Also gibt es wohl noch ein paar Bugs mit Packages unter Lazarus

Hoffe das sich Dave in absehbarer Zeit wieder meldet und diesen fiesen Käfer bekämpft.

PS: Die Events funktionieren jetzt auch unter Lazarus =D (nebenbei mit getestet )

MfG,
Eugen

[littleDave]

Zitat von EugenB:

Moin

Ich freue mich das diese Bugs gefixt wurden, hatte jedoch noch keine zeit diese zu testen. Da ich seit Samstag Windows 64 Bit benutze konnte ich SEII unter FPC bisher nicht lauffähig "machen". Es sind 2 Fehler (vllt sogar mehr aber kamn nur bis zum zweiten^^) nur bei den Assembler funktionen:

- Wechseln von EBP, ESP auf R*; Funktioniert nach paar Recherchen -> lässt sich Compilieren bis ->;
- PutOnFPUStackExtended (gibt es vllt eine andere lösung als dieses FLD zu nutzen?)

Da ich von Assembler generell kaum was verstehe (und nie verstehen werde^^) konnte ich da nur das erste Problem lösen. Werde mir aber so schnell wie möglich Lazarus auf 32Bit umstellen damit ich dann auch endlich mal die Events & Packages testen kann .

Mal sehen wie lange es dauert bis man die IDE & Packages auch unter FPC kompilieren kann (falls es noch nicht funtkioniert)

MfG,
Eugen

Die Script-Engine ist unter 64-Bit nicht lauffähig. Das liegt zum einen daran, dass ich mich noch nicht mit den 64-Bit-Assembler-Code auseinander gesetzt habe. Zum anderen kann ich das nicht testen, da ich "nur" ein 32-Bit-System habe. Daher wird sich bis auf weiteres an der 64-Bit-Unterstützung nichts ändern können

Zitat von EugenB:

Soo, habe mir jez die 32Bit Lazarus auf 64Bit Windows installiert, nun kann ich auch ganz normal wieder kompilieren. Die Packages habe soweit auch ganz einfach Konvertiert, soll ich die Patches dir zuschicken? Das selbe für die Samples? damit man nicht immer wieder die Samples neu per hand konvertieren muss ^^

Das kannst du gerne machen. Ich werde die Änderungen dann einpflegen.

Zitat von EugenB:

Zu dem bei der IDE kann man diese leider nicht komplett auf Lazarus laufen lassen da zB TSynCompletionProposal (müsste die klasse sein) es bei Lazarus nicht gibt, ich wollte diese mal implementieren =D aber dazu hab ich zuwenig SynEdit erfahrung =D. Vllt eine IDE erstellen die für Delphi als auch für Lazarus (vom Quelltext her) funktionieren würde?

Das übersteigt im Moment mein Zeitkontingent. Ich bin im Moment bis oben hin ausgelastet, daher ist es für mich im Moment nicht möglich, eine komplett neue IDE zu erstellen. Mich wundert es aber, dass es kein TSynCompletionProposal unter Lazarus gibt

Zitat von EugenB:

Mhm hätte da noch ne Frage zu den Packages, laut dem Quellcode der IDE werden alle Packages einmal am Start geladen, könnte man es nicht so machen das man die Packages erst lädt wenn diese im Script benötigt werden?

Das wird nicht so wirklich gehen: in den Packages ist da der Quelltext für die Script-Engine drinnen. Somit würde die Script-Engine das Script nicht kompilieren können, da der Quelltext fehlt.

Zitat von EugenB:

Btw, wie wäre es wenn man die Convert-Klasse fast genauso wie in .Net macht ^^ Convert.ToString() welche dann fast für alle Typen den String dazu ausgibt und das selbe für Int, Double usw

Das könnte man sich mal überlegen. Ich muss mal schauen, wie ich das am besten umsetze ... Wahrscheinlich wird es einfach so sein, dass man für die jeweiligen Basistypen eine Helper-Klasse erstellt.

Zitat von EugenB:

Btw 2nd, es fehlt eigentlich nur Arrays OBWOHL man kann ja auch einfach zB TIntegerList nutzen, also wäre es dann nicht vllt besser einfach anstatt arrays im script zu implementieren die Listen nutzen?

So das man bei so einer Variable

X : Array[0..12] of Integer

auch sowas nutzen könnte

X.IndexOf ; X.Add ; X.Delete usw

Es fehlen noch ein paar weitere wichtige Dinge: so kann man z.B. noch keine Records aus der Script-Engine heraus oder in die Script-Engine hinein zu schicken. Arrays wird es auf jeden Fall geben, jedoch weiß ich noch nicht, wann . A

Zitat von EugenB:

PS.: So langsam bräuchte ich zugriff aufs SVN und ggf deine email =D

Klären wir per PN

Zitat von EugenB:

PPS.: Wie wäre es wenn du SEII mal im Lazarus-Forum und/oder in der Mailliste präsentierst?^^ Dann würden diese bestimmt auch viele Nutzen ggf bei einigen Problemen helfen

Leider fehlt mir im Moment die Zeit sowas zu leiten, daher muss ich damit noch etwas warten.

Zitat von EugenB:

PPPS.: Mach weiter so, diese Script Engine stellt so langsam alle anderen in den Schatten -> Ich glaub ich sollte mal ne Übersicht machen, =D habe solangsam so viele Script Engines ausprobiert mit Lazarus =D

Danke für das Lob, jedoch fehlt da wie gesagt noch das ein oder andere.

Zitat von EugenB:

Hoi

nurzur Info, Plugins die man Lazarus mit MODE DELPHI kompiliert laufen auch bei der vorkompilierten IDE Dave ist wohl wieder sehr beschäftigt ^^. Mal sehen ob auch eigene Plugins laufen. *test* ...

Zitat von EugenB:

Zufrüh gefreut....

Die Plugins die man mit Lazarus Kompiliert egal ob mit "{$MODE DELPHI}" oder "{$MODE OBJFPC}{$H+}" funktionieren sowohl in der vorkompilierten IDE als auch bei selbst erstellten Programmen nicht.

Folgende Meldung versuche ich schon seit Tagen zu beseitigen:

Code:

Error: [Streams] [Line 14]: Unexpected end of file
Error: [Streams] [Line 0]: Could not compile the unit "Streams"
Error: [Collections] [Line 6]: Could not add the unit "Streams"
Error: [Collections] [Line 0]: Could not compile the unit "Collections"

Wenn ich mir jetzt diese Streams angucke, wie sie in der IDE aussieht, sehe ich kein "Unexpected end of file", alle Quellcodes sind normal angezeigt.

Also gibt es wohl noch ein paar Bugs mit Packages unter Lazarus

Das liegt wohl daran, dass (soweit ich weiß) Lazarus UTF-8-Strings verwendet und der Compiler an der Stelle wahrscheinlich abbricht. Muss aber da nochmal genauer schauen. Jedoch gibt es zuerst ein ganz wichtiges Update:

Version 0.4.3.0

Ich habe die Script-Engine bereits in einem großen Projekt im Einsatz und bin somit auf ein paar große Bugs gestoßen:

• Da ein Unit ja aus mehreren Dateien bestehen kann, ist es wichtig, die einzelnen Dateien in der richtigen Reihenfolge zu kompilieren. Dafür gibt es bei nativ eingebundenen Units bereits eine Priorty-Property. Diese Priorität gab es bisher in den Packages nicht. Daher habe ich eine optionale Funktion in die Package-API hinzugefügt. Diese Funktion heißt ganz einfach "IsExtender". Wenn diese Funktion "True" zurück gibt, wird die Unit erst später kompiliert. Hier mal ein Beispiel:
  
  Package 1: Streams: Dieses Package stellt die Basis-Klasse "TStream" in der Unit "Streams" zur Verfügung.
  Package 2: IO: Dieses Package stellt "TFileStream = class(TStream)" ebenfalls in der Unit "Streams" zur Verfügung.
  
  Wenn jetzt das Package IO mit der Unit "Streams" vor der Basis-Units "Streams" aus dem Package 1 zuerst kompiliert wird, kann das Package nicht kompiliert werden, da TStream noch nicht bekannt ist. Daher kann jetzt das Package 2 einfach bei der Unit "Streams" einfach sagen "IsExtender = True". Dann wird der Unit aus Package 2 erst nach der Unit von Package 1 kompiliert. *puh* - hoffe das war jetzt ein wenig verständlich
• Wenn man eine Klasse als "forward" deklariert (also TMyKlasse = class, und man diese Klasse in einer anderen Klasse als Variable speichert, kam es zu Zugriffsverletzungen
• try-except und try-finally Blöcke haben die Optimierung des Linkers nicht wirklich überstanden. Somit haben die Sprungadressen an eine falsche Stelle gezeigt.
• Es gab einen Fehler, wenn man Script-Methoden als TMethod benutzt und diese Script-Methoden strings in den Parametern hatten
• In der Runtime wurde das "not" bei boolean-Werten nicht immer korrekt ausgeführt
• Wenn man aus dem Programm heraus eine Script-Methode aufruft und diese dann eine Exception wird, wird der Script-Stack wieder hergestellt, damit man das Programm trotzdem noch weiter verwenden kann.
• Das exit-Statement sollte jetzt funktionieren
• Es gab einen Stack-Overflow wenn eine Unit sich selbst in die Uses-Liste mit aufgenommen hat.

Den Download gibts wie immer im ersten Post.

[littleDave]

Neues Update Version 0.4.4.0

Nach langer Zeit gibt es mal wieder ein Update. Changes:

• Neue Features
  • Es gibt eine neue Include-Unit: uSE2IncTypes. Darin ist bisher TPoint und TRect mit einigen Funktionen deklariert
  • Für jeden Standarttyp gibt es jetzt eine .ToString - Methode
  • Mann kann jetzt Konstanten zu Records, Klassen und Helper-Klassen hinzufügen
    Nun ist es möglich aus Records aus der Host-Anwendung an die Script-Engine zu übergeben - und zurück. Jedoch gibt es dabei leider noch ein paar Einschränkungen:
    • Alle records in der Host-Anwendung müssen als packed record deklariert sein
    • Es können noch keine verschachtelten Records übertragen werden.
    • Records, in denen sich strings befinden, können ebenfalls leider noch nicht übertragen werden
    • Die Funktionalität wurde noch nicht mit FreePascal getestet.
  • Man kann nun externe Methoden auch zu Records hinzufügen
• Änderungen im Script-Quelltext
  • Farbkonstanten (cl*) sind jetzt in die Colors-Klasse (z.B. Schwarz: Colors.Black)
• Behobene Bugs
  • Bei überladenen Methoden gab es ein Problem, sobald verschiedene Rückgabetypen verwendet wurden
  • Single oder Double-Konstanten waren immer NaN
  • Wenn bei Konstanten ein Typ mit angegeben wurde, wurde dieser nicht verwendet
  • Bei überladenen Methoden gab es ein Problem mit der Konvertierung der Parameter
  • Bei der Code-Completion konnte es vorkommen, dass der selbe Eintrag mehrmals vorkommt
• Performance
  • Die Ausführungsgeschwindigkeit wurde um bis zu 50% verbessert

Der Download befindet sich wie immer im ersten Post

Grüße