In CONZEPT 16 haben die Entwickler grundsätzlich die Möglichkeit, zwischen einer SDI (Single Document Interface) – oder MDI (Multiple Document Interface) – Anwendung zu wählen. Der wesentliche Unterschied beider Konzepte besteht in der Organisation der Anwendungsfenster.
In einer SDI-Anwendung kann jedes Fenster eigene Menüleisten und Toolbars besitzen. Zudem ist das Dialogfenster modal, dies bedeutet dass bei mehreren geöffneten Fenstern innerhalb der selben Applikation lediglich in dem aktiven Fenster gearbeitet werden kann. Diese Einschränkung gibt es in einer MDI-Anwendung nicht. In dieser Umgebung kann der Anwender wahlweise mit den geöffneten Dialogfenstern arbeiten. Für welches Fensterlayout sich der GUI Entwickler entscheidet, hängt im wesentlichen von den Anforderungen der Applikation ab.
Problemstellung
Auf dem CONZEPT 16-Client wird für jede Tabelle, die in einer Datenbank angelegt ist, ein Datensatzpuffer erzeugt. Über diesen Puffer kann jedes Feld in der Datenbank adressiert werden. Das Lesen und Ändern von Datensätzen wirkt sich generell auf den globalen Datensatzpuffer aus. Dieser Mechanismus kann sich allerdings bei einer MDI-Anwendung als Problem herausstellen, da es in dieser Umgebung möglich ist, Datensätze aus ein und derselben Tabelle gleichzeitig in mehreren Fenstern darzustellen. In diesem Fall arbeiten alle Fenster auf dem globalen Datensatzpuffer der Datei und beeinflussen sich daher gegenseitig.
Lösung
Die Lösung besteht darin, dass jedes MDI-Anwendungsfenster mit einem eigenen Datensatzpuffer arbeitet. Hierfür steht die Eigenschaft wpDbRecBuf
zur Verfügung. In Abhängigkeit der Felder, welche in dem MDI-Fenster bearbeitet werden, muss die dazugehörige Tabelle ausgewählt werden.
Ist die Eigenschaft gesetzt, wird die Verwaltung der MDI-Feldpuffer automatisch von CONZEPT 16 vorgenommen:
- Sichern der MDI-Feldpuffer
Das aktive MDI-Fenster verliert den Fokus durch das Wechseln in ein anderes Fenster innerhalb der Anwendung, oder durch einen Mausklick außerhalb der Anwendung. - Wiederherstellen der MDI-Feldpuffer
Das MDI-Fenster erhält den Fokus.
Was gilt es zu beachten
Das automatische Wiederherstellen des Feldpuffers wirkt sich störend aus, wenn in der MDI-Anwendung eine Aktion durchgeführt wird, in der Datensätze, die zu einer über wpDbRecBuf
ausgewählte Tabelle gehören, verarbeitet werden. Wechselt der Anwender während dieser Verarbeitung zwischen den MDI-Fenstern, wird dadurch der Feldpuffer geändert. Das gleiche gilt, wenn der Anwender aus der Applikation klickt und vor dem Ende der Verarbeitung wieder zurückkehrt.
Für beide Konstellationen gibt es eine Abhilfe:
- Ein Wechsel, zwischen geöffneten MDI-Fenstern während der Ereignisverarbeitung, lässt sich über die Option
_WinAppWaitCursorEvt...
verhindern. Je nach gewünschter Cursordarstellung stehen die Optionen_WinAppWaitCursorEvt
,_WinAppWaitCursorEvtArrow
und_WinAppWaitCursorEvtOS
zur Verfügung.Beispiel:
_App->wpFlags # _App->wpFlags | _WinAppWaitCursorEvt
- Das Wiederherstellen des MDI-Puffers nach dem Zurückkehren in die MDI-Applikation, wird mittels der Option
_WinAppFld2BufOff
verhindert.Beispiel:
_App-wpFlags # _App-wpFlags | _WinAppBuf2FldOff
Diese Option unterbindet den Update vom Datensatzpuffer der Objekte MdiFrame und RecList zum globalen Datensatzpuffer. Es ist daher zu beachten, dass die Option solange aktiv bleibt, bis sie wieder zurück gesetzt wird.
Option zurücksetzen:
_App->wpFlags # _App->wpFlags & ~_WinAppBuf2FldOff
2 Antworten
@Th.Eichele
In der Version 5.6 gab es keine Änderungen.
Es ist richtig, vor einer Verarbeitungsschleife sollten die Flags gesetzt werden.
d.h. vor einer Verarbeitungsschleife in einem MDI-Fenster sollten beide Flags gesetzt und hinterher wieder deaktiviert werden ?
hat sich hier seit 5.6 etwas geändert ? Seither gibt es bei Kunden ab und zu verstellte Puffer, die Ich nicht erklären kann.