8 Ablauf beim Programmstart
Die Startfunktion StartMegas, die dem Aufruf jeder Megasapplikation vorausgeht, registriert im GUI die Liste der erlaubten Sektionen und die zu der jeweiligen Sektion gehörende Scanfunktion. In der Analysephase der Frames ruft das GUI die registrierten Scanfunktionen, wenn es auf eine registrierte Sektion trifft. Innerhalb der Scanfunktion wird eine entsprechende Struktur im Freispeicher angelegt, die die Einträge in der Sektion aufnehmen kann. Dies ist der Grund warum bei der Registrierung der Scanfunktionen auch eine Vernichtungsfunktion mitgegeben werden muss.
Nach der Analyse des applicationframe wird dieser im allgemeinen auch erzeugt, dabei ruft das GUI die callback CBpMegCreateApplFrame(), in dem nun eine erste Prüfung erfolgt, ob die Sektionen MegGeneral und MegRoot überhaupt existieren. Zu diesem Zeitpunkt wird auch ein sogenannter private actionhandler im GUI bekannt gemacht, eine ausführliche Beschreibung desselben folgt später.
Es folgt der Versuch die Modustexte aus der Meldungsdatei zu holen. Geht dies aus irgendeinem Grund nicht, so werden Defaultwerte verwendet. Falls in der Sektion MegGeneral die Unterstützung von Sprachkennzeichen vereinbart wurde, legt Megas jetzt einen Buffer und die globale Variable GV_sprkzmegas in der Länge des Sprachkennzeichenfeldes (Feld 9, Datei 46) an.
Anschließend prüft Megas, ob in der Inidatei eine andere Frame-Reihenfolge vereinbart ist als in der MegGeneral Sektion. Über die Inidatei ist es dadurch möglich bestimmte Frames auszublenden. Es folgt eine Prüfung der Inidatei auf globale bzw. spezifische Einstellungen, bzgl. zugelassener Modi (Show, Modify, Create), Aktionen (Löschen<ja,nein>) und Startmodus. Hierbei haben die Inidateieinstellungen Vorrang vor dem CGW und spezifische wiederum haben Vorrang vor den allgemeinen.
Mit dem Anlegen einer Struktur MEGAPPL im Freispeicher und der Anbindung dieser Struktur an den Frame mittels GuiFrameSetData() hat es die Applikation bereits zur Hälfte geschafft. MEGAPPL enthält einen Zeiger auf eine Struktur vom Typ MEGGENERAL, dieser Zeiger erhält als Wert die Adresse der Strukturvariablen, die das Gui für die Analysephase verwendet hat. Nun wird das roottable belebt, indem die verschiedenen Buffer der MEGTABLE-Struktur angelegt werden (work, commit, query und save buffer). Es folgt die Abarbeitung der lookup- und Texteinträge, bis hin zu einer Vor- und Rückwärtsverkettung bei lookup und root. Texteinträge kennen ihren parent derzeit noch nicht.
Falls die Menge der Sätze im roottable eingeschränkt werden soll, so kann dies z.B. durch Angabe einer Nebenbedingung geschehen (mehr dazu später). Die Auswertung eines solchen Eintrages ist ebenfalls in CBpMegCreateApplFrame() abgehandelt.
roottable
Satzarten und Nebenbedingungen
Megas bietet die obengenannten Möglichkeiten die Menge der Datensätze in einer Datenbankdatei, die einer Megasapplikation zugänglich sind, einzuschränken. Die Satzart wird mit dem Schlüsselwort RecordType in der MegRoot Sektion vereinbart. Position und Längenangabe müssen mit dem ersten Feld im Bearbeitungspfad identisch sein, dies gewährleistet gegenüber einer Nebenbedingung bessere performance, ist aber weniger flexibel. Die CGW’s zu FST511 sind mit RecordType realisiert.
Eine Nebenbedingung ist eine Art Suchabfrage, die man derzeit in einer Zeile formulieren muss. Eine Nebenbedingung stellt man mit dem Schlüsselwort Constraint, siehe Anwender.hlp. Anders als bei der Satzart, wo ein fester Zeichenstring erwartet wird, kann nach der Positions- und Längenangabe eine Zeilenbedingung aus dem erweiterten Suchen folgen.
lookuptable
Texte und Sprachkennzeichen
private actionhandler
Im Laufe der Entwicklung stellte es sich heraus, dass innerhalb eines Gritereignisses nicht alle Methodenaufrufe von GRIT zum Erfolg führen, außerdem konnte man keine eigenen Ereignisse posten. GFT erweiterte Grit deshalb um die Userevents, die einen derartigen handler erst möglich machten. Ein Beispiel, wo der handler sehr erfolgreich eingesetzt wird, ist das posten des BufferChanged-Ereignisses. BufferChanged ist ein INFRA-spezifisches Ereignis, bei dem das GUI festgestellt hat, dass sich der Inhalt eines Buffers durch eine Benutzeraktion geändert hat. Eine Möglichkeit, die dieses Ereignis auslöst, ist der FocusIn auf einem anderen control des gleichen Frames. Es ist aber sehr heikel in einer FocusIn-callback z.B. den Focus auf ein ganz anderes control zu setzen. Ein weiterer Grund für den Einsatz solcher handler ist die Benutzung eigener Events, so ist z.B. der Suchlauf im Megas derart programmiert, das nach Zugriff auf einen Datensatz und anschließender Ermittlung ob er den Bedingungen genügt, ein QUERY_CONTINUE gepostet wird. Dies hätte man sonst mit Timerevents programmieren müssen, ein Verfahren, dass deutlich fehleranfälliger ist als Verwenden von solchen userevents.
Felder mit MegField Angabe im sibdef
Abfragen
Auskunft
Zustände und Berechtigungen