Um die Befehle zu nutzen, muss die Datei shared.h in den Quellcode included werden und die Datei shared.obj muss im makefile mit angegeben werden, damit der Linker die Datei einbinden kann.
#== CompileObjectFile ==
APLOBJS = $(ODIR)\test.obj \
$(ODIR)\shared.obj
|
Im Prinzip benötigt man folgende Befehle:
| Befehl | Beschreibung |
|---|---|
| sfLoadRecord | Lädt einen Record aus der Shared Datei |
| sfSaveRecord | Legt einen Record in der Shared Datei ab, bzw. aktualisiert einen Record |
| sfRemoveRecord | Löscht einen Record wieder aus der Shared Datei |
Jedem Befehl wird eine sogenannte Signatur übergeben. Diese Signatur besteht aus dem Namen des AddIn (mind. 8 Zeichen) und
durch , getrennt eine Bezeichnung, welche Daten dieses AddIn lesen möchte
Eine Signatur könnte also folgendermassen aussehen:
CAR_RACING,Auto
CAR_RACING,Level
CAR_RACING,Highscore
Damit wird es möglich, so eine Art INI-Datei für den PV zu haben. Die Daten, die dann tatsächlich geschrieben und gelesen werden,
sind binär abgelegt (wie bei allen Dateien, die durch AddIns verwendet werden) und stehen voll unter der Verantwortung
des Programmierers des AddIns.
Da man ein Programm aber auch wieder vom PV entfernen kann, muss man auch dafür sorgen, dass Einträge in der SHARED
Datei für dieses Programm auch wieder gelöscht werden. Daher sollte jedes Programm, das die SHARED Datei nutzt auch eine
Funktion anbieten, um alle Einträge dieses Programms aus der SHARED-Datei zu entfernen. Dann kann das Programm auch gelöscht werden.
Da die Einträge in der SHARED-Datei über den Namen des AddIns (bzw. was der Programmierer als AddIn-Namen angibt) gespeichert werden, sollten nur Namen verwendet werden, die tunlichst nicht von einem anderen Entwickler genutzt werden. Wenn man den gleichen Namen nutzt, wie das AddIn, haben andere Programme auch die Möglichkeit, auf die Daten zuzugreifen, wenn sie prüfen, ob das AddIn installiert ist.
Für Ergänzungen wenden Sie sich bitte an:
Jürgen Wagner