Topic       : Dokumentation zum Library-Maker
Author      : Karsten Lüdersen @ HH
Version     : MKlib.hyp 2.49
Subject     : Programmieren/Basic
Nodes       : 162
Index Size  : 5558
HCP-Version : 4
Compiled on : Atari
@charset    : atarist
@lang       : 
@default    : 
@help       : Hilfe
@options    : +g -i +y +z -t4 -d24
@width      : 75
View Ref-FileTips für die Library-Programmierung
Erste Hilfe
Anforderungen an die Struktur von Libraries                  Library-Maker

Falls der Library-Maker eine Library übersetzt und der Basic-Editor sie
ohne Fehlermeldung einlädt und auch der Compiler das Programm klaglos
übersetzt und das Programm (im Interpreter oder Compiler) trotzdem abstürzt
oder sonstwie merkwürdig verhält lesen Sie bitte auf jeden Fall die Seite
Erste Hilfe.

Damit aus einer Basic-Datei eine Library erzeugt werden kann muß der
Quelltext bestimmte Voraussetzungen erfüllen:

1. Eine Library darf nur aus Prozeduren und Funktionen bestehen.
Außerhalb von Prozeduren und Funktionen darf es nur Kommentare und 
"Einklappklammern" geben. Zusätzlich ist ab der Version 2.49 der Befehl 
COMPILER erlaubt, wenn danach eines der beiden Steuerworte "LIB_MAKER OFF" 
oder LIB_MAKER ON" folgt.

2. Die erste Prozedur gibt der Library ihren Namen. Sie sollte deshalb
im wesentlichen einen Copyrightvermerk haben, etwa in dieser Form:

DEF PROC Libraryname: PRINT "Copyright der Library": END_PROC

Ab der Version 2.45 des Library-Maker darf die Prozedur eingerückt
sein. Es dürfen auch Kommentarzeilen oder Einklappklammern davor
stehen. Es muß aber eine Prozedur sein. Eine Funktion führt zu einer
Fehlermeldung.

3. Der Quelltext muß eine Prozedur mit dem Namen Exported_Symbols
haben. Sinnvoll ist es, sie gleich als zweite in den Quelltext
aufzunehmen. Sie enthält durch mindestens einmaliges Vorkommen die
Namen aller Prozeduren, Funktionen, Variablen, Felder und Labels, die
auch von außerhalb der Library aufrufbar sein sollen. Während es bei
Prozeduren und Funktionen sinnvoll sein kann, großzügig mit der
globalen Verfügbarkeit zu sein, sollten Sie mit globalen Variablen und
Feldern vorsichtig umgehen. Je weniger, desto besser. So können
versehentliche "Datenlecks", die später zu schwer nachvollziehbaren
Fehlern führen, am einfachsten vermieden werden.

Labels sollten in dieser Prozedur gar nicht auftauchen. Falls Sie
wirklich meinen, daß dies unumgänglich ist, müssen sie mit GOTO bzw.
GOSUB aufgerufen werden.

4. Prozeduren und/oder Funktionen dürfen nicht verschachtelt sein. In
jeder Zeile darf es nur genau eine Prozedur/Funktion geben.

5. Strukturbefehle müssen in der richtigen Reihenfolge erscheinen.
Also erst FOR und später NEXT, erst REPEAT, dann UNTIL usw.

6. Strukturen müssen eindeutige Ein- und Ausgänge haben, also zu jedem
FOR genau ein NEXT etc. Diese müssen sich auch in der selben Prozedur
bzw. Funktion befinden.

7. IF-Konstruktionen müssen auch "ordentlich" sein, also bei
mehrzeiligem IF muß ein ENDIF vorhanden sein und es muß sich hinter dem IF 
befinden.

8. Für SELECT-Strukturen gilt auch entsprechendes, der Library-Maker
prüft diese aber nicht. D.h. eine Library mit einer fehlerhaften
SELECT-Struktur wird ohne Fehlermeldung übersetzt. Beim Hinzulinken zu
Programmen wird diese Library aber zu Fehlern führen, die dann nur
schwer zu finden sind. Erst recht für AnwenderInnen der Library, die
den Quelltext nicht besitzen ...

9. Nie mit GOTO oder GOSUB von einer Prozedur in eine andere springen.
Wenn die andere Prozedur ansonsten nicht aufgerufen wird, so wird sie
auch nicht in das Compilat übernommen. Der Sprungbefehl mit GOTO bzw.
GOSUB führt dann in's Nirwana. Und guter Programmierstil ist das schon gar
nicht ...

10. Alles an Programmcode, was für eine Prozedur oder Funktion
benötigt wird, muß in dieser selbst enthalten sein. In Libraries
müssen deshalb z.B. DATA-Zeilen innerhalb der Prozedur stehen, in der
sich auch der READ-Befehl befindet. Alternativ dazu können DATA-Zeilen
auch in einer Pseudo-Prozedur stehen, die von der Prozedur mit dem
READ-Befehl durch ein "IF 0 THEN Pseudoprozedur" scheinbar aufgerufen
wird. Von dieser Alternative wird aber abgeraten!

11. Ein einzeiliges IF ist ein einzeiliges IF. Ein einzeiliges IF ist
eine IF-Konstruktion, in der der THEN-Zweig in der selben Zeile steht.
Hinter einem einzeiligen IF darf keine Struktur beginnen (z.B. eine
Schleife oder eine weitere IF-Struktur), die über mehrere Zeilen geht.
Meines Wissens ist so etwas auch im Basic völlig undefiniert.

12. MEMORY_BLOCK ist in Libraries nicht möglich.

13. Einzeilige Funktionen müssen am Ende der Zeile ein END_FN haben.