[1] [2] [3] [4] [5]

Teil 2 - Managerklassen (FWK_MGR)

FWK_MGR_BASE

FWK_MGR_LANGUAGE

FWK_PARAM

FWK_MGR_REGISTRY

FWK_MGR_RESIZE

Teil 3 - Initialisierung Basis- und Managerklasen

1. Hauptprogramm Projekt Loader:

Das Hauptprogramm besteht nur noch aus ganz wenigen Zeilen und tut folgendes:

1.1. Setzen der Klassenbibliotheken für Basis- und Managerklassen.

Sowohl aus dem Framework (FWK_BASE.VCX, FWK_MGR.VCX) als auch projektspezifische Subklassen davon (PROJ_BAS.VCX, PROJ _MGR.VCX).

1.2. Erzeugen des Loader-Objektes mit =createobject("proj_mgr_loader")

1.3. Falls selbiges erfolgreich, Start der Anwendung mit =oLoader.start()

2. Init der Framework-Manager-Basisklasse:

Durch das Createobject wird die Init-Methode des PROJ_MGR_LOADER (PROJ_MGR.VCX) durchlaufen. Dieser reicht den Aufruf sofort weiter an seine Parentklasse FWK_MGR_LOADER (FWK_MGR.VCX) und diese tut das selbe hoch zur Managerbasisklasse FWK_MGR_BASE (FWK_BASE.VCX). Diese initialisiert sich wie folgt:

2.1. Superbasisobjekt erzeugen:

Vorbemerkung: Das Superbasisobjekt ist die wichtigste Konzepterweiterung der Basis-Klassenbibliothek FWK_BASE.VCX gegenüber den üblichen Ansätzen des einfachen Subclassing aller Klassenarten von Visual FoxPro. Das Objekt FWK_BASE wird als globales Objekt oBASE _vor_ allen anderen Objekten instanziiert. Fast alle wesentlichen Methoden-Aufrufe (z.B. Init, Destroy, Refresh, Click usw.) werden von den Framework-Basisklassen aller Objekte auf dieses globale Objekt umgeroutet (Beispiel: Methode Commandbutton::Init ruft auf oBase.Init( THIS ) ) und übergeben eine Selbstreferenz als Parameter. Dadurch kann das Superbasisobjekt allen normalerweise redundanten Code aufnehmen (z.B. gleiche Codeabschnitte in Textbox und Spinner oder in Listbox und Combobox). D.h. Code, der für mehr als eine Klasse gültig ist, wird im Superbasisobjekt hinterlegt und nur noch rein klassenspezifischer Code ist in der Subklasse vorhanden (=Redundanzfreiheit).

2.1.1. Prüfung Vorhandensein Superbasisobjekt

Ohne das Superbasisobjekt kann aber kein weiteres Objekt instanziiert werden, deshalb prüfen die Managerbasisklasse mit dem Funktionsaufruf =this.loadobase() das Vorhandensein von oBase. Falls nicht vorhanden:

2.1.1. Laden der gewünschten Superbasisklasse

Aus der Eigenschaft "THIS.coBaseClass" wird der Name der Klasse des Superbasisobjektes geholt. Dadurch ist man nicht an die Klasse des Frameworks gebunden, sondern kann auf der Subklasse PROJ_MGR_LOADER entsprechend auf eine Subklasse der Superbasisklasse PROJ_BASE verweisen, in der projektspezifische Anpassungen vorgenommen werden können.

2.1.2. Erzeugen des Basisobjektes

Mit createobject() wird dann das Basisobjekt erzeugt und dieser Vorgang in "THIS.lcreateobase" vermerkt, damit im Destroy dieses Objektes auch die Superbasisklasse wieder entfernt werden kann.

2.2. Initialisierung des Superbasisobjektes:

2.2.1. Zuweisung einer eindeutigen Kennung

Zuerst weist sich das Superbasisobjekt mit "THIS.cUniqueID = SYS(2015)" eine eindeutige Kennung zu. Fehlen dieser Kennung bedeutet, daß es sich beim Init-Aufruf um das eigene Init handeln muß <g>.

Erläuterung: In Visual FoxPro gibt es bisher nur die Funktion COMPOBJ(), die einen aufwendigen Vergleich aller Properties durchführt, um bei zwei Referenzen festzustellen, ob diese nicht auf dasselbe Objekt verweisen. Durch einfach Zuweisung einer eindeutigen Kennung muß man nur noch die Kennung vergleichen ( oObject1.cUniqueID = oObject2.cUniqueID => Gleiches Objekt mit versch. Referenzen). Dies funktioniert auch problemlos beim Vergleichen von Objekten auf mehrern Instanzen der gleichen Maske (dort wäre der Objektname und sogar der komplette Objektpfad identisch - interessant vor allen Dingen bei Drag&Drop-Operationen).

2.2.2. Publizieren Selbstreferenz

Als nächstes wird mit "public oBase" und "oBase = THIS" eine globale Referenz auf sich selbst erzeugt, damit alle nachfolgenden Objekte das Superbasisobjekt über diese globale Referenz ansprechen können.

2.2.3. Erzeugen des Languagemanagers

Sofern die Eigenschaft THIS.lNoTranslation nicht auf .T. steht (d.h. Übersetzungen global abgeschaltet werden, interessant für Oneways, die ja rein englisch laufen könnten), wird mit dem Aufruf "=THIS.setlanguagemanager()" als nächstes der Sprachmanager instanziiert, da er von fast allen nachfolgenden Objekten benötigt wird.

2.2.3.1. Laden der gewünschten Languagemanagerklasse

Aus der Eigenschaft "THIS.cLanguageclass" wird der Name der Klasse des Languagemanagers geholt. Dadurch ist man nicht an die Klasse des Frameworks gebunden, sondern kann in der Subklasse PROJ_BASE entsprechend auf eine Subklasse von FWK_MGR_LANGUAGE verweisen, in der projektspezifische Anpassungen vorgenommen werden können.

2.2.3.2. Erzeugen des Basisobjektes

Mit createobject() wird dann der Languagemanager erzeugt und dieser Vorgang in "THIS.lCreatedLangMan" vermerkt, damit im Destroy der Superbasisklasse auch der Languagemanager wieder entfernt werden kann. Siehe Initialisierung Languagemanager.

2.2.4. Individuelle Init-Methode aufrufen

Mit "return THIS.CustomInit()" wird die zusätzliche Custom-Init-Methode. In dieser kann man in einer Subklasse eigenen projektspezifischen Code plazieren.

Erläuterung: Alle Framework-Klassen besitzen eine Custom-Init-Methode, da es bei komplexen Objekten manchmal etwas schwierig ist, mit einem Dodefault() im Init einfach den Supercode auszuführen und dann noch schnell etwas hintendranzuhängen. Dies gilt insbesondere für das Superbasisobjekt . In der Custom-Init-Methode aller Objekte kann man einfach direkt Code schreiben ohne Dodefault() und irgendwelche anderen Regelungen beachten zu müssen und man kommt dann immer _nach_ dem Init-Code des Superbasisobjektes (alle Inits rufen dieses Superinit auf) und _vor_ dem klassenspezifischen Code (statt beim Dodefault() im normalen Init() _danach_)..

2.3. Initialisierung der Languagemanagerklasse:

Es stehen über den Languagemanager hauptsächlich die Methoden GETLITERAL und SETLANGUAGE zur Verfügung. Letztere wird von allen Basisklassen zur Selbstübersetzung bei Initialisierung über oBase.SetLanguage aufgerufen (Hinweis: Der Umweg über oBase ist notwendig, da bei einsprachigen Applikationen garkein Languagemanager existieren würde!).

2.3.1. Initialisierung über Framework-Manager-Basisklasse

siehe unter 3. das gleiche Beispiel für die Loader-Klasse

Kurzfassung: Addieren des Pfades auf Liter, Öffnen der Tabelle Liter mit der Order Liter, Abfragen auf Datei TRANSLAT.TMP und Publizieren von oLanguage als Selbstreferenz.

2.3.2. Initialisierung über Superbasisklasse

siehe unter 2.4. das gleiche Beispiel für die Loader-Klasse

2.3.3. Individuelle Initialisierung Languagemanager

Es wird derzeit nur die Sprache "ger" als Default für die Benutzeroberfläche eingestellt. (Hinweis: Eine entsprechende Standortabhängige Laderoutine fehlt noch.)

2.3.4. Initialisierung der projektspezifischen Subklasse

siehe unter 6. das gleiche Beispiel für die Loader-Klasse

Anhang zu 2.3.:

Funktion GETLITERAL: Erhält per Referenz die Parameter tcLiteral, tcCaption, tcToolTip, tcStatus, tcHelp. In tcCaption kann wahlweise auch "CAPT", "TOOL", "STAT", "HELP" stehen, so daß nur das gewünschte Feld der Literaldatei zurückgeliefert wird. Kann jederzeit aufgerufen werden. (Hinweis: Bei Fehlen eines Literals in der Entwicklungsumgebung wird derzeit noch nicht die Maske zum sofortigen Einpflegen von neuen Literalen aufgerufen)

Funktion SETLANGUAGE: Holt sich mit this.getliteral( lcCaption, "", @lcToolTip, @lcStatus ) die benötigten Strings und setzt Caption, ToolTipText und StatusBarText des jeweils als Referenz übergebenen Objektes mit dessen Eigenschaften bzw. denen seines Parents (zweiter Parameter). (Hinweis: Holt derzeit noch nicht bei allen Klassen die ursprünglichen Literale aus der Sicherung (s.u.) zurück, so daß ein erneuter Aufruf mit einer anderen Sprache noch nicht durchgängig zuverlässig ist).

2.4. Initalisierung des Loaders über das Superbasisobjekt:

Diese Initialisierung wird von _allen_ Objekten einheitlich durchlaufen. Deshalb ist nur verhältnismäßig wenig Code hier plaziert worden, da sonst die Performance sinken könnte. Die vielen Assertions zum Sicherstellen des Vorhandenseins diverser Parameter, Eigenschaften und Methoden der aufrufenden Objekte werden in der ausgelieferten Version einfach abgeschaltet (siehe SET ASSERT OFF in der VFP-Hilfe).

2.4.1. Setzen eindeutige Kennung

siehe dazu "2.2.1. Zuweisung einer eindeutigen Kennung"

Ergänzung: Falls Kennung schon vorhanden, wird die Initialisierung abgebrochen.

2.4.2. Sichern Caption

Die Caption des Objektes wird für spätere weitere Übersetzungen gesichert.

2.4.3. Required

Sofern die Eigenschaften "lRequired" gesetzt ist, wird die Methode THIS.Required() aufgerufen.

2.4.3.1. Aufruf von Required()

Hier werden einheitlich Eigenschaften für zwingend notwendige Felder gesetzen.

Hinweis: Dies ist derzeit leider nur eine Baustelle...

2.4.3. InGrid

Sofern sich ein aufrufendes Objekt in einem Grid befindet, wird das Flag lInGrid gesetzt, so daß man später jederzeit diesen Schalter abfragen kann, ohne sich jedesmal zum Parent durchhangeln zu müssen. Desweiteren erfolgt ein:

2.4.3.1. Aufruf von InGridInit()

Hier werden Grid-spezifische Eigenschaften einheitlich gesetzt, z.B. Margin oder Borderstyle, damit keine Grid-spezifische Subklasse von allen Objekten notwendig ist (dies würde den Vererbungsbaum sonst an der Programmier- statt an der Programlogik orientieren).

2.4.4.CustomInit

siehe "2.2.4. Individuelle Init-Methode aufrufen" incl. Erläuterung dort.

Hinweis: Temporär ist das Routen der Managerbasisklasse durch die Initialisierung der Superbasisklasse abgeschaltet. Stattdessen wird nur "this.cUniqueID= Sys(2015)" und "this.lInit = .T." gesetzt. Dies ist nur für Testzwecke.

[1] [2] [3] [4] [5]