Anleitung zum Dialog Simulator

Transkript

1 Inhaltsverzeichnis A Seeheim-Modell 14 Inhaltsverzeichnis Anleitung zum Dialog Simulator Version Tobias Nowack 1. Oktober 2004 Inhaltsverzeichnis 1 1 Einleitung 4 2 Change Log Version B XML-Kommunikation 15 B.1 Kommunikation der Plugins B.2 Kommunikation der Plugins unter Berücksichtiung von Masterplugin und XML-Viewer C USimDlg 17 D 19 D.1 Abbildungen D.2 Quellcode D.2.1 Inputplugin D Project D Unit - Form D.2.2 Outputplugin D Project D Unit - Form D.2.3 Masterplugin D Project D Unit - Form Vorwissen Erzeugen eines Plugins Anlegen der Dateien Notwendige Anpassungen des Quellcodes Unit Project Erzeugen eines Inputplugins Senden von Daten Empfangen von Daten Erzeugen eines Outputplugins Empfangen von Daten Senden von Daten Erzeugen eins Masterplugins Initialisieren des Masterplugins init plugin call Activate Plugin Hauptprogramm 11 9 XML Viewer Toolbar 13 1 c Tobias Nowack,

2 Warnung 2 Change Log Warnung Auch wenn der Code des Simulators unter Delphi 6 und Delphi 7 problemlos läuft, ist es nicht möglich, Plugins bzw. Hauptprogramm untereinander zu mischen. Deshalb sind sowohl die mitgelieferten DLL s, als auch die dcu der Basisklasse jeweils in beiden Versionen beigelegt. Verwenden Sie nur die für ihre Delphiversion übersetzten Programmteile. 1 Einleitung Der Dialogsimulator ist ein Programm, das es ermöglichen soll, einfach dialogbasierte Oberflächen zu gestalten und diese dann an Bedienern zu testen. Die eigentliche Oberflächengestaltung der einzelnen Dialoge erfolgt mit Delphi, aufsetzend auf den Basisklassen des Simulators. Das Erstellen dieser Dialogplugins wird in der folgenden Anleitung ausfühlich beschrieben. Der Simulator besteht aus 5 Teilen: 1. dem Hauptprogramm, von dem aus die einzelenen Plugins geladen, die Dialoge ausgewählt und angezeigt werden; (siehe Bild 1) 104 Abbildung 1: Hauptfenster des Simulators, mit eingebundenem Masterplugin 2. den einzelnen, vom Dialogentwickler in Delphi zu entwerfenden Dialogen (im folgenden auch Inputplugins genannt), deren Interaktion mitprotokolliert wird; 3. den zu den Inputplugins korrespondierenden Outputplugins; 4. einem speziellen Masterplugin, das sich wie in Grafik 1 mit dem Hauptfenster verbindet und als übergeordnete Steuerinstanz fungiert; 5. dem XML Überwachungsfenster. (siehe Bild 3) Ziel des Simulators ist es,bedienoberflächen einfach entwerfen zu können (Rapid Prototyping) und diese an Probanden zu testen und damit zu optimieren. Dazu können die Bedieneraktionen protokolliert werden, damit sie anschließend auswertet in eine Überarbeitung der Oberfläche einfließen können. Zu diesem Zwecke ist es mit dem Simulator möglich, alle Interaktionen im XML Überwachungsfenster zu beobachten bzw. die Interaktionen auch anschließend in einer Datei abzuspeichern. 2 Change Log 2.1 Version Main Window (Abs. 8) c Tobias Nowack, c Tobias Nowack,

3 4 Erzeugen eines Plugins 4 Erzeugen eines Plugins Abspeichern der Dialogpositionen & -größen, außerdem des Sichtbarkeitszustandes Erweiterung um das Masterplugin (welches sich in das Hauptfenster integrieren kann) XML-Viewer (Abs. 9) Scrollbalken am Ausgabefenster Speichern der Ansicht vom Ausgabefenster Erweiterung der Filter Ausgabe des timestamps in ms Speichern der Einstellungen Autoload, wenn nicht durch gespeicherte config überschrieben docu: Erklärung zur XML Ausgabe output Alle vom Dialogentwickler erstellten Outputplugins (Abs. 6) werden in diesem Verzeichnis abgelegt. Der XML-Viewer, auch als Outputplugin erzeugt findet sich auch in diesem Verzeichnis wieder. 4.1 Anlegen der Dateien Zum Erzeugen neuer Plugins, starten Sie Ihre Delphi Entwicklungsumgebung. Erzeugen sie mittels Datei neu eine leere DLL. Zu dieser DLL fügen sie ein Form hinzu. Des weiteren geben Sie unter Projekt, Optionen, Verzeichnis, Bedingungen, Suchpfad den Pfad zu dem Verzeichnis basis an. (Abb. 2) Master Plugin (Abs. 7) 3 Vorwissen 105 Der Dialogentwickler sollte Grundkenntnisse der Programmierumgebung Delphi aufweisen. Für einen Einstieg bietet sich die Einführung in Delphi 4 auf 1 an. 4 Erzeugen eines Plugins Dieses Kapitel ist allgemeingültig für alle Typen von Plugins. Es handelt sich hierbei um das grundlegende Anlegen von Dateien und die notwendigen Quellcodekorrekturen. Es ist nicht sinnvoll, sich ein Muster dieses Grundmusters anzulegen und anschließend nur noch zu kopieren. Der Aufwand der dann benötigten Korrekturen gleicht dem Neuanlegen. Ein Blick in den Verzeichnisbaum des Simulators vorweg lohnt sich. Hier finden sich vier Unterverzeichnisse mit folgenden Inhalten: basis Hier findet sich die Datei USimDlg.dcu, die die vorübersetzte Klasse TSimDlg enthält. Hier können weitere Basisklassen, sofern benötigt, vom Dialogentwickler abgelegt werden. input Dieses Verzeichnis wird zukünftig alle Inputplugins (Abs. 5) enthalten. Im Auslieferungszustand ist es leer. main In diesem Verzeichnis befindet sich das Hauptprogramm Simulator.exe. Ausserdem finden Sie hier das mitgelieferte Masterplugin toolbar.dll (Abs. 7) Jedes vom Dialogentwickler eingsetzte Masterplugin muss auch in diesem Verzeichnis zu finden sein.!achtung Nicht verwendete Masterplugins mit einer anderen Endung als dll versehen! 1 Stand Abbildung 2: Projektoptionendialog 4.2 Notwendige Anpassungen des Quellcodes Unit1 Fügen Sie im Quelltext zu den uses USimDlg hinzu. Ändern Sie in der Typendeklaration type die Basisklasse von TFom zu TSimDlg. type TForm1 = class(tsimdlg) c Tobias Nowack, c Tobias Nowack,

4 4 Erzeugen eines Plugins 5 Erzeugen eines Inputplugins 106 Entfernen Sie unter var die Variablendeklaration Form1 : TForm1 für das Form und, falls keine weiteren Variablen definiert sind, auch das var. var From1 : TForm1; Fügen Sie am Ende der Interfacedeklaration (direkt von implementation) noch die Funktion implementation hinzu. Diese Funktion wird auch als erste in dem Implementation Abschnitt wie folgt angelegt, fügen Sie dazu: implementation result := TForm1.Create(nil); ein. Während der Erzeugungsphase des Dialogs, also in der OnCreate Routine, muss die Funktion SetRegData(FPlugin, FLib, FMenuGroup, FMenuItem, FPluginType, FAuto- Load) aufgerufen werden. Das leere Funktionsgerüst erzeugen Sie durch einen doppelklick auf das OnCreate Ereignis im Objektinspektor. Die Parameter im einzelnen: FPlugin [String] Name des Dialogplugins (Inputplugin) FLib [String] Name der korrespondierenden lib. (Outputplugin) FMenuGroup [String] Name der Menügruppe in der Hauptanwendung, wo das Plugin zu finden sein soll FMenuItem [String]Name des Menüitems im Menü der Hauptanwendung. FPluginType [TPluginType] Typ des Plugins, mögliche Werte sind hier: Input, Output, Master (keine Strings) FAutoLoad [boolean]gibt an, ob das Plugin automatisch nach dem Programmstart geladen werden soll. (Wird durch gespeicherte Werte überschrieben) procedure TForm1.FormCreate(Sender: TObject); SetRegData( Test_Plg, Test_Lib, Test_DLL, Test_Plg, Input, False); Der hier dargestellte Aufruf von SetRegData initiert das Input Plugin mit dem Namen Test Plg des korrespondierendem Outputplugins Test Lib. In der Menüstruktur des Hauptprogramms lässt es sich in der Menügruppe Test DLL unter dem Menüpunkt Test Plg aufrufen. Standardmäßig wird das Plugin nicht dargestellt (False). c Tobias Nowack, Project1 Im Quellcode für die dll, die noch unter dem Reiter Project1 zu finden ist, ist folgende Erweiterung nötig. Dazu fügen Sie hier vor den abschließenden end Block noch folgenden Block ein: exports initplugin; 5 Erzeugen eines Inputplugins Bei einem Inputplugin handelt es sich um die Präsentationschicht (Abb. 4). Es stellt die graphische Nutzerschnittstelle dar. Alle Ein- und Ausgaben müssen von dem dem Inputplugin behandelt werden. Mit dem Wert Input für den Parameter FPluginType (Abs ) wird festgelegt, daß es sich um ein Inputplugin handelt. Speichern Sie nun alle zum Projekt gehörende Dateien im Verzeichnis input. Übersetzen Sie das Projekt und starten dies mit dem Hauptprogramm Simulator.exe aus dem Verzeichnis main. 5.1 Senden von Daten Um die Daten, die im Eingabeplugin gesammelt werden, an das entsprechende Ausgabeplugin zu übergeben, verwenden Sie die Funktion SendData(data);. über die Verwendung dieser Funktion finden Sie im Anhang D zu dieser Anleitung. Bei dem Parameter data handelt es sich um einen String, Sie sollten also darauf achten, andere Datentypen vorher in Strings zu konvertieren. Da diese Daten ohne weitere Bearbeitung in den XML-Stream integriert und übertragen werden, sollten Sie darauf achten, daß sie folgendes Format einhalten: <data-type></data-type> <data></data> Innerhalb der data-type Tags sollten Sie angeben, aus welchen vorherigen Datentypen sie den XML-Strom generiert haben, sodass Sie für eine Auswertung des gespeicherten Datenstromes diese wieder in das richtige Format konvertieren können. Durch diesen Mechanismus, sind Sie frei in der Wahl ihrer zu übertragenden Daten. Als kleines Beispiel für eine eine komplexere Datenstruktur wird hier die Datenstruktur zum Loggen der Mausklicks demonstriert: <data-type> <integer name="x"/> <integer name="y"/> </data-type> <data> <X>116</X> c Tobias Nowack,

5 6 Erzeugen eines Outputplugins 7 Erzeugen eins Masterplugins 107 <Y>183</Y> </data> 5.2 Empfangen von Daten Wenn Sie in ihrem Inputplugin Datenantworten (Abb. 5) Ihres Outputplugins verarbeiten wollen, müssen Sie die Funktion TSimDlg.NewData(FData : String); in ihrer Klasse überschreiben. Für ein Beispiel schauen Sie in Anhang D. Sie erhalten in der Variablen FData den kompletten XML-Datenstrom, wie er zwischen den Plugins verwendet wird. Aus diesem Datenstrom, können Sie dann die von Ihnen zur weiteren Verarbeitung benötigten Daten extrahieren. Der Datenstrom sieht dann wie folgt aus: <answer> <lib></lib> <plugin></plugin> <data-type></data-type> <data></data> </answer> Für die Verarbeitung der Daten bietet sich ein einfacher XML parser wie z.b: der TJvSimpleXML aus dem Project JEDI. In dem im Anhang D aufgeführten Beispiel wird die Komponente zum Auslesen der Stringdaten jeweils in der Funktion NewData verwendet. Ein Hinweis noch zur Verwendung der oben genannten Komponente: Sollte man sich nicht 100% sicher sein, daß das gefragte XML-Tag in den vorliegenden Daten enthalten ist, sollte man mit der Funktion assigned() überprüfen, ob das gewünschte Item (Beispielsweise eine in XML-Tags geklammerte Variable) enthalten ist und sich erst dann dessen Wert ausgeben lassen. Andernfalls kann es zu Fehlern bzw. zum Absturz des Simulators kommen. Elem := SimpleXml.Root.Items.ItemNamed[ data ].Items.ItemNamed[ Edit1 ]; if assigned(elem) then Label1.Caption := Elem.Value; 6 Erzeugen eines Outputplugins Bei dem Outputplugin handelt es sich um die Anwendungsschicht (Abb 4), der Schnittstelle zur NPM-Maschine bzw. den Simulatorbackends. Auch zur Erstellung eines Outputplugins müssen die grundlegenden Quellcodeanpassugen (Abs. 5 ) zuvor durchgeführt werden. Mittels des Wertes Output für den Parameter FPluginType (Abs ) wird festgelegt, daß es sich um ein Outputplugin handelt. Speichern Sie nun alle zum Projekt gehöhrende Dateien im Verzeichnis output, übersetzen Sie das Projekt und starten dies mit dem Hauptprogramm Simulator.exe aus dem Verzeichnis main. 6.1 Empfangen von Daten Die Datenverarbeitung durch ein Outputplugin verläuft ähnlich der eines Inputplugins. Der Unterschied ist jedoch, daß nicht ein User Event das Senden der Daten auslöst, sondern c Tobias Nowack, das Plugin durch den Empfang von Daten durch die Funktion TSimDlg.NewData(FData : String); aktiviert wird (Abb. 5). Die Daten vom Eingabeplugin liegen dem Outputplugin wie folgt vor: <command> <lib></lib> <plugin></plugin> <data-type></data-type> <data></data> </command> 6.2 Senden von Daten Bei einem Outputplugin findet das Senden der Daten im Regelfall direkt im Anschluß an die Verarbeitung durch die Empfangsroutine statt. Sie wird mittels der Funktion SendData(data); durchgeführt, und auch die Datenstruktur sollte wieder, wie schon bei Inputplugin beschrieben (Abs. 5.1), aufgebaut sein. 7 Erzeugen eins Masterplugins Unter den vom Dialogentwickler zu erzeugenden Plugins nimmt das Masterplugin eine Sonderstellung ein. Auch das Masterplugin ist ein Element der Präsentationsschicht (Abb. 4). Input- und korrespondierendes Outputplugin arbeiten direkt zusammen und bilden eine geschlossene Einheit (Abb. 5). Aufgesetzt auf diese Einheit, kann ein Masterplugin die Darstellung der Daten verschiedener Inputplugins zusammenfassen oder im Kontext eines interaktiven Hilfesystems den Bediener bei der Auswahl der von ihm für die entsprechende Aufgabe benötigten Dialoge (Inputplugins) unterstützen. Es verhält sich von seinen Basisfunktionen her genauso wie ein normales Input- oder Outputplugin, ist allerdings um einige Funktionen erweitert.! Wichtig ist, daß es pro Anwendung nur maximal ein Masterplugin geben darf! 7.1 Initialisieren des Masterplugins Das Masterplugin wird zusammen mit der Hauptanwendung im Verzeichnis main gespeichert. Bei der Erzeugung des Plugins wird in der SetRegData() Routine der Plugintyp (Abs ) Master vergeben. Bei einem Masterplugin kann eine feste Koppelung des Plugins mit dem Hauptfenster erwünscht sein. Dies wird durch den Aufruf der Funktion SetPosition Fixed(true); erreicht. Feste Koppelung von Masterplugin und Hauptanwendung heißt, das Masterplugin wird als Bestandteil der Hauptanwendung in ihr Fenster eingebettet (Abb. 1). Bei der losen Koppelung ist das Masterplugin ein eigenständiger Dialog, der frei auf der Oberfläche positioniert werden kann. Da ein Masterplugin ähnlich wie das in Abschnitt 9 erklärte XML Viewer Plugin alle XML c Tobias Nowack,

6 8 Hauptprogramm Daten durchgereicht (Abb. 6) bekommt, können dort einzelne Ausgaben ausgewertet werden. Um diese Felder auch vor der ersten Benutzung des entsprechenden Plugins anzeigen zu können und um noch ein paar Einstellungen im XML Viewer vorzunehmen, ist es notwendig, daß während der Initialisierung auch noch die Funktion init plugin call(); aufgerufen wird (Erklärung siehe Abschnitt 7.2). Die vollständige OnCreate Routine eines Masterplugins sollte dann wie folgt aussehen: procedure TForm1.FormCreate(Sender: TObject); SetRegData( master,,,,master,true); setposition_fixed(true); init_plugin_call(); 9 XML Viewer 9 XML Viewer Beim Starten des Hauptprogramms Simulator.exe werden alle *.dll s aus den Verzeichnissen Input und Output automatisch mitgeladen. Unter den normalen durch den Nutzer erzeugten Plugins, nimmt das Outputplugin XML Viewer (siehe Bild:3) eine Sonderstellung ein. Dieses Plugin protokoliert alle XML-Datenströme, die zwischen den Plugins ausgetauscht werden. 7.2 init plugin call Durch das Aufrufen der Funktion init plugin call(); in der OnCreate Routine eines Masterplugins wird an jedes Plugin ein Init call geschickt, der in der XML-Datenstruktur folgendermaßen aufgebaut ist: 108 <data-type> <boolean name="init"/> </data-type> <data> <init>-1</init> </data> Sollten Sie, wie im angehängten Beispiel (D) beabsichtigt, bestimmte Daten eines oder mehrere Plugins während der Initialisierung bzw. im Betrieb auswerten wollen, sollten Ihre Plugins auf den zuvor beschriebenen init call reagieren, außerdem sollte die im Masterplugin von der Basisklasse überschriebene procedure NewData(FData:String); diese Daten aus dem ankommenden Datenstrom auswerten. 7.3 Activate Plugin Eine weitere Besonderheit des Masterplugins ist, daß es andere Plugins aufrufen und somit sichtbar bzw. unsichtbar machen kann. Dazu ist die Prozedur procedure Activate Plugin(FPlugin : String); vorgesehen, deren Parameter FPlugin bei Inputplugins den Pluginnamen und bei Outputplugins den Libnamen übergeben bekommt. 8 Hauptprogramm Zum Hauptprogramm muss nicht viel gesagt werden. Die einzige Funktion, die Erwähnung finden sollte, ist die Funktion Save, im Menü File. Diese Funktion speichert die Einstellung zur Größe und Position der einzelnen Plugins und zu ihrem Sichtbarkeitszustand. Die Daten werden im Basisverzeichnis in einer XML Datei Save.xml abgelegt. Die dort gespeicherten Einstellungen werden beim nächsten Programmstart mitgeladen und überschreiben die in den Plugins vorgegebenen Initialwerte. c Tobias Nowack, Abbildung 3: XML Viewer Plugin Ausserdem werden alle Mausklicks und alle Positions- / Größenveränderungen von Fenstern, die der Nutzer auf / in einem der Plugins macht, aufgezeichnet. Die Ansicht ist frei konfigurierbar, es kann ausgewählt werden, welche Daten im Protokollfenster angezeigt werden, ausserdem auch, in welchem Zeitabstand die Daten für diese Mausklicks bzw. Windowveränderungen protokolliert werden. Das interne Protokoll führt diese auch weiterhin mit. Beim Abspeichern kann dann entschieden werden, ob die aktuelle Ansicht abgespeichert werden soll oder das interne Protokoll in einer Datei abgelgt werden soll. Der Zeitstempel eines jeden XML-Datenpaketes wird vom XML-Viewer dem Datenstrom zugefügt und ist nicht Bestandteil desselben im Programm. Die Genauigkeit des Protokolls beträgt 1 ms, wobei der Datenabgleich zum Hauptprogramm und unterhalb der Plugins nur alle 100 ms stattfindet. Die Einstellungen die im XML-Viewer-Dialog gemacht werden, um die Ausgabe am Bildschirm nach folgenden Kriterien zu filtern: Mouse Action (bzw. Zeitintervall, in dem die Mouse Actions aufgezeichnet werden); c Tobias Nowack,

7 10 Toolbar A Seeheim-Modell Window Action (bzw. Zeitintervall, in dem die Window Actions aufgezeichnet werden); Commands von den Input zu den Output Plugins; Answers von den Output an die Input Plugins; Activate Calls von den Master plugins; Init Calls zur Initialisierung des Masterplugins mit den Daten aus den einzelnen Plugins; können gespeichert werden und werden beim nächsten Programmstart automatisch geladen. A Seeheim-Modell Toolbar Im Verzeichnis main befindet sich ein mitgeliefertes Masterplugin Toolbar. Wird dieses eingebunden, das heißt die Datei toolbar.dll im Verzeichnis main belassen, wird im Hauptprogramm zusätzlich zu der Menüleiste eine Buttonleiste angezeigt, die sich durch die Antwort der Plugins auf den Init Call zusammenstellt. Die erwartete Antwort ist wie folgt in data-type definiert: <data-type> <xml name="button"> <string name="name"/> <string name="icon"/> <string name="hint"/> </xml> </data-type> Name bezeichnet für ein Inputplugin den Pluginnamen, für ein Outputplugin den LibnNamen. Icon ist der Pfad und der Dateiname eines 22 px x 22 px großen bmp Bildes, welches auf der Toolbar sichtbar ist. Abbildung 4: Das Seeheim-Modell für Bedienoberflächen und Applikationen Das Seeheim-Modell (Abb. 4), benannt nach der Seeheim- Konferenz User Inferface Technik ausgetragen im Schloß Seeheim bei Konstanz, ist das Basismodell zur Trennung von Applikation und UI. Bei diesem Modell wird eine Anwendung in drei Schichten aufgeteilt: die Präsentationsschicht (der statische Teil der Bedienoberfläche), die Dialogmanagementschicht (der dynamische Teil der Bedienoberfläche) und die Applikationsschicht. Bei der Erstellung einer Benutzeroberfläche müssen die Schnittstellen zwischen den unterschiedlichen Schichten definiert werden. Die Präsentationschicht, der sichtbare Teil einer Anwendung, dient dem Nutzer zur Interaktion mit der Maschine. Die Dialogmanagementschicht stellt das Verbindungsglied zwischen den Eingaben auf der grafischen Bedienoberfläche und den nachgelagerten maschinenseitigen Anforderungen. Die Applikationsschicht ist die Schnittstelle zur eigentlichen Anwendung bzw. Maschine. Hint ist der Hinweistext, der beim Überfahren des Buttons mit der Maus erscheint. Bei der Verwendung diese vorgefertigten Plugins entfällt die Möglichkeit für den Dialogentwickler, selbst ein Masterplugin anzufertigen und einzusetzen. c Tobias Nowack, c Tobias Nowack,

8 B XML-Kommunikation B XML-Kommunikation B XML-Kommunikation B.1 Kommunikation der Plugins B.2 Kommunikation der Plugins unter Berücksichtiung von Masterplugin und XML-Viewer 110 Abbildung 5: Kommunikation der Plugins Abbildung 6: Kommunikation der Plugins unter Berücksichtiung von Masterplugin und XML-Viewer c Tobias Nowack, c Tobias Nowack,

9 C USimDlg C USimDlg 111 C type USimDlg TPluginType = (Input, Output, Master); TRegPlugin = record Name : string; // Plugin Name MenuGroup : string; // Menue Group where Plugin will be registerd // If you want to add to &File oder &Edit menu you must use // use it with & at the ning MenuItem : string; // Menue Item name where Plugin will be executed PluginType : TPluginType; // Define if it is an input or output Pulugin Lib : string; // Define which lib will be called from this plugin AutoLoad : boolean; // Define if the plugin will be automaticly loaded // if application is starting TSimDlg = class(tform) private { Private declarations } HostApp : TApplication; RegData : TRegPlugin; old_top, old_width, old_left, old_height : Integer; Position_Fixed, init_call : Boolean; Name_List : TStringList; public { Public declarations } constructor Create(Owner: TComponent); // This function will be called by the OnHide event of the // Dialog window. If you want to use your own OnHide function // override this Function from the Father procedure FormHide(Sender: TObject); virtual; // This function has to be overided, the XML Data stream // has to be splited and displayed. procedure NewData(FData : String); virtual; // This function has to be called to send the XML Data // stream to the main application. // It should not be neccessary that you override the // function itself. // The Data Stream has to be prepared and put in the // Variable Data procedure SendData(FData : String); // This function initialize the RegData varaible with // all necessary values vor the plugin. // It schould be executed during form cration that the // main application has all necessary information about // the plugin during initialisation procedure SetRegData(FPlugin, FLib, FMenuGroup, FMenuItem : String; FPluginType : TPluginType; FAutoLoad : boolean); // This function is only used in master Plugins to call // other Dialogs to show. // If you want an other Plugin be showen with the master // Plugin then you have to call Activate_Plugin(<plugin_Name>) // or for libs call Activate_Plugin(<lib_name>) procedure Activate_Plugin(FPlugin : String); // This function is only used in master Plugins to do an // init call to all plugin s. // This init call will be have the normal data structure // (decribed in the manual) with // <data-type><boolean>init</boolean></data-type> // <data> <init>true</init></data> // Because we have to call all plugins each by each // we need to use the procedure SendData(FData) //! So don t forget to inherited the base class function // if you overrid it and use the init function! //! Even if you don t use this function on your own you // need to call it in show form of the master plugin to // set variables in xml_viwer! procedure init_plugin_call(); // This function is only used in master Plugins to combind // the plugin with the master window on top. // If you say true, you won t have an top line. procedure SetPosition_Fixed(FPosition : Boolean); //!! DO NOT EDIT // This function s are for the communication between Main window // and Dialg. procedure SetHostApp(Host : TApplication); function GetInitCall() : Boolean; procedure init_master_plugin(fname_list: TStringList); function GetRegData() : TRegPlugin; function GetPosition() : Boolean; protected // This function will be called by Every Window Message and if a // Mousebutton is down, it will send the mouse Data to the system. c Tobias Nowack, c Tobias Nowack,

10 D D procedure WndProc(var Message: TMessage); override; D D.1 Abbildungen uses SysUtils, Classes, UPlg_Test1_Dlg1 in UPlg_Test1_Dlg1.pas {Plg_Test1_Dlg1}, USimDlg in..\basis\usimdlg.pas ; {$R *.res} exports initplugin; //, getdata; D Unit - Form unit UPlg_Test1_Dlg1; interface 112 D.2 Quellcode D.2.1 D Inputplugin Project library Plg_Test1; Abbildung 7: Fenster des Beispiels { Important note about DLL memory management: ShareMem must be the first unit in your library s USES clause AND your project s (select Project-View Source) USES clause if your DLL exports any procedures or functions that pass strings as parameters or function results. This applies to all strings passed to and from your DLL--even those that are nested in records and classes. ShareMem is the interface unit to the BORLNDMM.DLL shared memory manager, which must be deployed along with your DLL. To avoid using BORLNDMM.DLL, pass string information using PChar or ShortString parameters. } uses Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, UsimDlg, StdCtrls, Buttons, JvComponent, JvSimpleXml; type TPlg_Test1_Dlg1 = class(tsimdlg) Label1: TLabel; BitBtn1: TBitBtn; Edit1: TEdit; SimpleXml: TJvSimpleXml; procedure FormCreate(Sender: TObject); procedure BitBtn1Click(Sender: TObject); procedure NewData(FData : String); override; private { Private declarations } public { Public declarations } implementation {$R *.dfm} c Tobias Nowack, c Tobias Nowack,

11 D D 113 result := TPlg_Test1_Dlg1.Create(nil); procedure TPlg_Test1_Dlg1.FormCreate(Sender: TObject); SetRegData( Test_Plg, Test_Lib, Test_DLL, Test_Plg, Input, False); procedure TPlg_Test1_Dlg1.BitBtn1Click(Sender: TObject); var data : String; data := <data-type><string name="edit1"/></data-type><data><edit1> + Edit1.Text + </Edit1></data> ; SendData(data); procedure TPlg_Test1_Dlg1.NewData(FData : String); var data : String; Elem : TJvSimpleXmlElem; SimpleXml.LoadFromString(FData); // If you have subitemes in xml code in data area then you have to // use such an constructed. // Even if can not be sure that all calls will have the data you // expect to find, you should first check if an ItemNamed[ yours ] // is assigend before you try to access the value. if assigned(simplexml.root.items.itemnamed[ data ]. Items.ItemNamed[ init ]) then // If Master Plugin ist Master: data := <data-type><string name="edit1"/></data-type><data><edit1> + Edit1.Text + </Edit1></data> ; // If Master Plugin ist Button: { data := <data-type><xml name="button"><string name="name"/> + <string name="icon"/><string name="hint"/></xml></data-type> + <data><button><name>test_plg</name><icon/> + <Hint>Test_Plg</Hint></Button></data> ; } SendData(data); Elem := SimpleXml.Root.Items.ItemNamed[ data ].Items.ItemNamed[ Edit1 ]; if assigned(elem) then Label1.Caption := Elem.Value; D.2.2 D Outputplugin Project library Lib_Test1; { Important note about DLL memory management: ShareMem must be the first unit in your library s USES clause AND your project s (select Project-View Source) USES clause if your DLL exports any procedures or functions that pass strings as parameters or function results. This applies to all strings passed to and from your DLL--even those that are nested in records and classes. ShareMem is the interface unit to the BORLNDMM.DLL shared memory manager, which must be deployed along with your DLL. To avoid using BORLNDMM.DLL, pass string information using PChar or ShortString parameters. } uses SysUtils, Classes, USimDlg in..\basis\usimdlg.pas, UPlg_Test1_Lib1 in UPlg_Test1_Lib1.pas {Plg_Test1_Lib1}; {$R *.res} exports initplugin; D Unit - Form unit UPlg_Test1_Lib1; interface uses Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, USimDlg, StdCtrls, JvComponent, JvSimpleXml; type TPlg_Test1_Lib1 = class(tsimdlg) Label1: TLabel; Label2: TLabel; SimpleXml: TJvSimpleXml; procedure FormCreate(Sender: TObject); procedure NewData(FData : String); override; private { Private declarations } public { Public declarations } c Tobias Nowack, c Tobias Nowack,

12 D D 114 implementation {$R *.dfm} result := TPlg_Test1_Lib1.Create(nil); procedure TPlg_Test1_Lib1.FormCreate(Sender: TObject); SetRegData( Test_Plg, Test_Lib, Test_DLL, Test_Lib, Output, False); procedure TPlg_Test1_Lib1.NewData(FData : String); var Input_Data, Output_Data : String; Elem : TJvSimpleXmlElem; SimpleXml.LoadFromString(FData); Elem := SimpleXml.Root.Items.ItemNamed[ data ]. Items.ItemNamed[ Edit1 ]; if assigned(elem) then Input_Data := Elem.Value; Output_Data := <data-type><string name="edit1"/></data-type><data><edit1> + Die Input Daten: + Input_Data + sind angekommen.</edit1></data> ; SendData(Output_Data); D.2.3 D Masterplugin Project library master; { Important note about DLL memory management: ShareMem must be the first unit in your library s USES clause AND your project s (select Project-View Source) USES clause if your DLL exports any procedures or functions that pass strings as parameters or function results. This applies to all strings passed to and from your DLL--even those that c Tobias Nowack, are nested in records and classes. ShareMem is the interface unit to the BORLNDMM.DLL shared memory manager, which must be deployed along with your DLL. To avoid using BORLNDMM.DLL, pass string information using PChar or ShortString parameters. } uses SysUtils, Classes, Umaster_dlg in Umaster_dlg.pas {Master_Dlg}, USimDlg in..\basis\usimdlg.pas ; {$R *.res} exports initplugin; D Unit - Form unit Umaster_dlg; interface uses Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms, Dialogs, USimDlg, StdCtrls, JvComponent, JvSimpleXml; type TMaster_Dlg = class(tsimdlg) Button1: TButton; GroupBox1: TGroupBox; Button2: TButton; GroupBox2: TGroupBox; Label1: TLabel; SimpleXml: TJvSimpleXml; procedure FormCreate(Sender: TObject); procedure Button1Click(Sender: TObject); procedure Button2Click(Sender: TObject); procedure NewData(FData : String); override; private { Private declarations } public { Public declarations } implementation c Tobias Nowack,

13 D {$R *.dfm} result := TMaster_Dlg.Create(nil); procedure TMaster_Dlg.FormCreate(Sender: TObject); SetRegData( master,,,,master,true); setposition_fixed(true); init_plugin_call(); procedure TMaster_Dlg.Button1Click(Sender: TObject); Activate_Plugin( Test_Plg ); procedure TMaster_Dlg.Button2Click(Sender: TObject); Activate_Plugin( XML_Viewer ); 115 procedure TMaster_Dlg.NewData(FData : String); var Elem : TJvSimpleXmlElem; inherited; SimpleXml.LoadFromString(FData); if (SimpleXml.Root.Name = command ) then if (SimpleXml.Root.Items.ItemNamed[ plugin ].Value = Test_Plg )then Elem := SimpleXml.Root.Items.ItemNamed[ data ].Items.ItemNamed[ Edit1 ]; if assigned(elem) then Label1.Caption := Elem.Value; c Tobias Nowack,