6.	Rebuild-Funktion
------------------------

Wenn  Sie eine neue Anwendung starten oder die aktuelle verlassen, so
wird	 Ihr   aufgebautes   System   von   Info-Fenstern   natrlich
berschrieben.	Ein  besonderes Feature des Programms ist jedoch, da
es  die  so berschriebene Konfiguration nach Mglichkeit vollstndig
wiederherstellt,   sobald   Sie  es  anschlieend  wieder  aktivieren
(Mentitel  anklicken).  Es  werden  alle  Fenster  (soweit  mglich)
wieder	erzeugt  und  die im Speicher gehaltenen Datei-Inhalte in dem
vorher	verlassenen  Zustand angezeigt. Beachten Sie also, da offene
Fenster  entsprechenden Speicherplatz blockieren knnen, wenn Sie sie
nicht schlieen.

Die  Rebuild-Funktion  bietet  den Vorteil, die Fenster-Konfiguration
in  eine  andere  Applikation  'hinberretten'	zu  knnen. Dies gilt
besonders  fr	Programme, die fast den gesamten verfgbaren Speicher
fr  sich  reservieren,  so  da Accessories dann kaum noch Spielraum
haben  (das  sind z.B. viele Textprogramme wie WORDPLUS oder TEMPUS).
Mit  1st  Guide  knnen  Sie  in  diesem Fall alle bentigten Fenster
vorher	 ffnen,  so  da  diese  Programme  von  vornherein  weniger
Speicher  bekommen. Nach dem Start des Programms kann dann problemlos
auf die Konfiguration zugegriffen werden.

Alle   bisherigen   Betriebssystemversionen   haben  die  unangenehme
Eigenschaft,  da Accessories nicht als eigenstndige GEMDOS-Prozesse
betrachtet  werden.  Dies  hat zur Folge, da Speicher, der durch ein
Accessory  beim  Betriebssystem  angefordert  wird,  immer der gerade
laufenden  Hauptapplikation  zugeordnet  wird.	Wenn  man  nun	diese
Hauptapplikation  verlt,  so	wird  automatisch  aller von ihr (und
dummerweise   eben  auch  von  benutzten  Accessories)	angeforderter
Speicher durch das Betriebssystem freigegeben.

Verlt  man  nun  ein Programm, in welchem man mit 1st Guide Dateien
geladen  hat, so kann 1st Guide diese eben nicht restaurieren, da der
dazu   reservierte   Speicherplatz   ohne   Rcksicht	auf  Verluste
freigegeben wird.

Um  nun  zu erkennen, ob ein Fenster "rebuildet" werden kann, benutzt
1st  Guide  eine  von Atari dokumentierte Systemvariable, die auf den
aktuellen  GEMDOS-Proze  zeigt  (unter MSDOS wird dazu eine Funktion
namens	 "get	PSP"   benutzt).  Dieser  Zeiger  auf  den  aktuellen
Proze-Descriptor  wird nun bei jedem Laden einer Datei abgefragt und
zu  den  Fensterdaten mit gesichert. Falls nun eine Rebuild-Situation
eintritt,   fragt   1st   Guide   den	Zeiger	 auf   den  aktuellen
Proze-Descriptor  erneut  ab  und  vergleicht	diesen	Wert  mit dem
gesicherten.   Bei   einer   bereinstimmung  kann  nun  das  Fenster
"rebuildet"  werden, sonst nicht. Zustzlich wird der gesicherte Wert
noch  mit den Werten der Parent-Proze-Zeiger verglichen, da auch und
gerade	in  diesem Fall ein Rebuild mglich ist. Dies ist mglich, da
die  Proze-Descriptoren  nichts  anderes  als	die  Basepages	sind,
welche	ber  den Parent-Proze-Pointer untereinander verkettet sind,
so  da  sich  1st Guide durch diese Proze-Liste 'durchhangeln' kann
(der  "Programm-Segment-Prfix"  unter MSDOS bietet diese Mglichkeit
nicht, hier kann nur der eigentliche Wert verglichen werden).

Die  hier  beschriebene  Vorgehensweise  ist vllig legal und benutzt
nur  dokumentierte  Features  (kein Schreibzugriff auf "actpd" !), so
da   zuknftige   Betriebssytemversionen   keine  Probleme  bereiten
sollten.   Falls   Accessories	einmal	den  Status  von  'richtigen'
GEMDOS-Prozessen   erhalten   sollten	(dies	ist   zu   wnschen),
funktioniert  diese  Methode  ebenfalls  und  es  knnen  stets  alle
Fenster  "rebuildet"  werden,  da  das	Programm  dann	immer  seinen
eigenen Proze-Descriptor "zu sehen" bekommen mte.

Nachtrag:  Unter MultiTOS gibt es keine Probleme, da weder Accessory-
noch Applikationsfenster durch das System geschlossen werden.