[zurück zum Inhalt]
 

5.2. Erweiterungen ("Plug-Ins") entwicklen


1. Einleitung

Ab der Version 1.2BETA2 ist es möglich, in die Schulverwaltung Erweiterungen, sog. "Plug-Ins", einzuhängen.
Diese Plugins müssen sich alle im Unterverzeichnis \plugins der SoPralino Schulverwaltung befinden. Beim Starten werden sie automatisch erkannt und eingerichtet.

Es gibt zwei Arten von Plug-Ins. Zum einen die "normalen" Plugins, die in das Menü unter dem Punkt "Erweiterungen" eingehangen und nur auf Verlangen des Benutzers aufgerufen werden. Alternativ können Sie dazu auch das Fenster unter "Spezial->Erweiterungen..." verwenden.
Die andere Sorte Plug-Ins sind die "GUI-basierenden" Plugins. Diese werden beim Start der Schulverwaltung aktiviert und bekommen ein eigenes Register im Hauptfenster zur Verfügung gestellt.

2. Selbst entwickeln

Ein Plug-In ist nichts anderes als eine DLL, die bestimmte Funktionen implementieren muss. Sie können also mit jeder Programmiersprache, die in der Lage ist DLLs zu erstellen, Plugins für die Schulverwaltung entwickeln. Übrigens: das funktioniert auch mit "normalen" Programmen, wenn diese die entsprechenden Funktionen exportieren. Sie müssen dann nur die Endung von "EXE" in "DLL" umbenennen.
Die fertige DLL kopieren Sie einfach in das Verzeichnis \plugins Ihrer Schulverwaltung

Ein Plugin muss dabei folgende Funktionen bereitstellen bzw. exportieren, die dann jeweils von der Schulverwaltung aufgerufen werden:

Bei einem "normalen" Plugin sind dies:

hasgui()
Rückgabewert ist ein Integer, dessen Wert folgende Bedeutung hat: 0 = das Plugin hat keine GUI, 1 = das Plugin hat eine GUI (bei normalen Plugins sollte hier immer eine 0 vom Plugin zurückgegeben werden).
getname()
Rückgabewert ist ein LPSTR, der auf den Namen des Plugins zeigt (zum Typ LPSTR vgl. das "Windows API Reference Manual")
start(HWND)
besitzt keinen Rückgabewert - diese Funktion startet das Plugin und übergibt das Fenster als HWND

Bitte beachten Sie die Kleinschreibweise der Funktionsnamen.
Bei einem Plugin, das die GUI mit verwendet, müssen folgende, zusätzliche Funktionen implementiert werden:

hide()
Rückgabewert: keiner - versteckt alle, vom Plugin generierten Anzeigen
show()
Rückgabewert: keiner - veranlasst das Plugin alle seine generierten Objekte wieder anzuzeigen
update()
Rückgabewert: keiner - wird aufgerufen, wenn Werte in der Schulverwaltung verändert wurden
neu()
Rückgabewert: keiner - wird aufgerufen, wenn im Hauptfenster das zum Plug-In gehörende Registerblatt aktiviert und im Menü "Neu" gewählt wurde
aendern()
Rückgabewert: keiner - wird aufgerufen, wenn im Hauptfenster das zum Plug-In gehörende Registerblatt aktiviert und im Menü "Ändern" gewählt wurde
loeschen()
Rückgabewert: keiner - wird aufgerufen, wenn im Hauptfenster das zum Plug-In gehörende Registerblatt aktiviert und im Menü "Löschen" gewählt wurde
close()
Rückabewert: keiner - wird aufgerufen, wenn das Plugin wieder beendet wird - dient zum "Aufräumen".

Ich habe bewusst versucht, die Funktionen so einfach wie möglich zu halten, damit es mit den verschiedenen Programmiersprachen keine Probleme gibt. Die übergebenen Werte halten sich alle an die Windows-API Konventionen (einmal HWND und einmal LPSTR).

3. Was ist mit den Daten?

Wie Sie sicher festgestellt haben, mache ich nirgendswo Angaben, wie das Plugin an die Daten aus der Schulverwaltung gelangen kann. Ich habe es mit hier einfach gemacht und keine Datenbank-Abfragefunktionen implementiert. Stattdessen verweise ich hier auf die Datei "aktuell.sdb". Diese Datei enthält stets alle, gerade in der Schulverwaltung aktuell verwendeten Daten. Ihr Plugin sollte also nur auf dieser Datei arbeiten. Das Datenformat ist in Abschnitt 5.3. dieser Dokumentation offengelegt und hoffentlich einfach zu verstehen.

Diese Vorgehensweise bietet zum einen für mich den geringsten Aufwand :-) und zum anderen ist so sicher gestellt, dass wirklich alle Programmiersprachen mit diesem Verfahren zurecht kommen.

Bei einem "normalen" Plug-In ohne GUI, wird die modifizierte Datei "aktuell.sdb" nach dessen Beendigung automatisch von der Schulverwaltung neu eingelesen - der Programmierer braucht sich in einem solchen Fall nicht um dieses Problem zu kümmern.
Anders sieht die Sache bei einem GUI-Plugin aus. Die Schulverwaltung kann nicht selbst entscheiden, wann das Plugin eine Änderung vorgenommen hat. Zu diesem Zweck exportiert die Schulverwaltung eine Funktion "updatesv()", die weder einen Aufrufparameter noch einen Rückgabewert erwartet.
Diese Funktion muss das GUI-Plugin aufrufen, nachdem es die Daten verändert hat. In das Plugin eingebunden werden kann diese Funktion z.B. mit der Windows-API-Funktion "GetProcAdress()".

4. Das SDK

Es gibt auf der Homepage der Schulverwaltung ein Software-Development-Kit zum herunter laden. In ihm befinden sich Beispiele für Borland C++, C++ Builder und Visual C++, sowie noch weitere Anmerkungen bzgl. der Plugin-In-Entwicklung.
 

[zurück zum Inhalt]