Beschreibung der Plugin-Schnittstelle

Einleitung

Mit dieser Plugin-Schnittstelle habe ich etwas fabriziert, was eigentlich so gar nicht geht (wenn man den vielen Newsgroups und "Experten" glauben schenken will). AT HTML Editor 32 ist ein reines in Visual Basic programmiertes Programm. Dennoch dachte ich mir, daß eine Erweiterung mit selbstprogrammierten Komponenten durch den Benutzer sinnvoll wäre, so, wie es auch andere Programme ermöglichen. Ich hatte verschiedene Konzepte entwickelt, so u.a. auch eine Variante reiner textbasierender Plugins, die auch der erstellen kann, der nicht der DLL-Programmierung mächtig wäre. Dennoch habe ich mich für ein DLL-basierendes Interface entschieden, weil zum einen u.a. auch ein textbasierendes Plugin aufgesetzt werden kann und zum anderen die Implementierbarkeit von weiterer (beliebiger) Funktionalität DLL-basierend wesentlich besser möglich und flexibler ist. Also habe ich meinem VB-Programm ein flexibles Plug-Interface spendiert, daß ganz "normale" DLLs dynamisch (!) zur Laufzeit lädt und entlädt. Und somit habe ich Visual Basic mit Delphi- und/oder C++-DLLs verheiratet. Dagegen funktionieren ActiveX-DLLs mit diesem Interface nicht. PureBasic-DLLs funktionieren nur eingeschränkt bzw. erlauben nur den Aufruf ohne Datenübergabe.


Mögliche Probleme

Die Tatsache, daß ich hier ein Visual-Basic-Programm mit einer Plugin-Schnittstelle zum dynamischen Anbinden von DLLs versehen habe, birgt einige Probleme in sich. Insbesondere, was die Übergabe von Text aus einem Plugin heraus in einen Code-Editor betrifft. VB hat nicht ein so ausgefeiltes Speicher-Management wie z.B. Delphi oder C++. Werden Zeichenmengen von mehr als 1200 Zeichen (1200 Byte) vom Plugin zurückgegeben, kann das zum Absturz führen. Aber es ist auch möglich, daß das erst bei Mengen von mehr als 10000 Zeichen (10000 Byte) passiert. Das scheint von System zu System unterschiedlich zu sein, deshalb habe ich mich entschlossen, die Zeichenmenge nicht zu begrenzen.
Desweiteren kann es zu Schwierigkeiten bei der Übergabe von Dateinamen aus einem Plugin kommen, die dann von AT HTML Editor 32 geöffnet werden soll. Kurze Dateinamen führen öfter zu diesen Schwierigkeiten als lange Dateinamen. Aber auch hier war das von System zu System unterschiedlich.
Wohlgemerkt, diese Probleme sind nicht in erster Linie fehlerhafte Programmierung, sondern auf das Verhalten von VB-Programmen zu Delphi- oder anderen Programmen zurückzuführen, weil ich hier ein VB-Programm mit Delphi- und anderen Programmen quasi "verheiratet" habe.


Architektur

Jeder wird dafür Verständnis haben, daß ich hier nicht alle technische Einzelheiten darlegen werde. Das würde auch den Rahmen sprengen, zumal diese Informationen auch gar nicht notwendig wären zum Schreiben eigener Plugins. Dennoch soll hier kurz das Konzept der Architektur angesprochen werden, um Entwicklern das Verständnis zu erleichtern.

Zwei Dinge sind wichtig für das Funktionieren:
1. AT HTML Editor sucht alle Plugins (ob EXE oder DLL) im Unterverzeichnis "plugins".
2. Das Geheimnis der dynamischen DLL-Anbindung steckt zum Teil in der pluginwrapper.dll im Programmverzeichnis.

Dadurch, daß die Plugin-Schnittstelle teilweise selbst ein Plugin ist, kann sie jederzeit geupdatet werden, ohne AT HTML Editor 32 erneut anpassen zu müssen. Wenn man so will, ist auch hier das seit AT HTML Editor 32.3 umgesetzte modulare Konzept der Komponenten konsequent angewandt.


Rückgabetypen

Die Plugin-Schnittstelle kennt 4 Rückgabetypen.

1. Markierter Text zum Plugin
Hiermit wird der im Code-Editor markierte Text an das Plugin zur weiteren Bearbeitung übergeben ohne daß das Plugin diesen Text wieder zurück gibt. Das ist z.B. dann sinnvoll, wenn der Text anderweitig weiterverarbeitet werden soll.

2. Markierter Text zum/vom Plugin
Hiermit wird der im Code-Editor markierte Text an das Plugin zur weiteren Bearbeitung übergeben. Nach Bearbeitung durch das Plugin erfolgt eine Rückgabe des bearbeiteten Textes. Dieser ersetzt dann den im Code-Editor markierten Text. Ist kein Text markiert, wird der Text aus dem Plugin an der Cursorposition zusätzlich im Code-Editor eingefügt. Das ist dann nützlich, wenn z.B. per Plugin eine Tabelle oder Frameset generiert werden soll.

3. Dateiname zum Plugin
Hier wird lediglich der Dateiname des aktuellen Code-Editors an das Plugin übergeben. Das ist z.B. dann nützlich, wenn man eine bearbeitete Datei mit einem kleinen FTP-Uploader automatisch schnell mal in das FTP-Verzeichnis "schieben" möchte. Auch wäre denkbar, hiermit einen kleinen externen Debugger oder Syntaxchecker zu realisieren.

4. Dateiname vom Plugin
Hiermit ergibt sich die Möglichkeit, z.B. aus einem externen Dateimanager oder FTP-Downloader schnell die übergebene Datei in AT HTML Editor 32 zur Bearbeitung zu öffnen.


Ein Plugin für AT HTML Editor 32.3 schreiben

Am besten läßt sich das anhand von praktischen Beispielen erklären. Im nachfolgenden wird jeder Rückgabtyp als Delphi-Code gezeigt. Im Code selber sind genügend ausreichend Erklärungen, die jedem versierten Programmierer genügen sollten. Besteht trotzdem noch weiterer Erklärungsbedarf, dann entweder auf die Homepage von AT HTML Editor 32 schauen oder mich einfach per E-Mail kontaktieren.

    1. Markierter Text zum Plugin
    2. Markierter Text zum/vom Plugin
    3. Dateiname zum Plugin
    4. Dateiname vom Plugin

Damit Plugins auch ganz gefahrlos außerhalb von AT HTML Editor 32.3 getestet werden können, gibt es auf der Homepage von AT HTML Editor 32 einen Plugin-Tester, mit dem das selbstentwickelte Plugin eben getestet werden kann. Der Plugin-Tester ist ebenfalls ein VB-Programm mit zum AT HTML Editor 32.3 identischer Plugin-Schnittstelle.