infra:NET Expert
ich bin User
 
×
(c) iN|ES GmbH, 2025
iN|ES GmbH • Gottlob-Bauknecht-Str.35, 75365 Calw • tel +49 7051 - 793 200 0  • Support-Hotline +49 7051 - 793 200 8 • support@ines-gmbh.de
Datenschutzerklärung • Impressum
[GuiFramePatch]
Alle nachfolgend beschriebenen Einträge dienen zusammen mit dem Eintrag "EventsOnActiveFrame” in anderen Gui-Sektionen dazu, in Programmen mit mehreren Dialogen die Eingaben über Register vornehmen zu lassen.
Beispiele
In "435 Aufträge bearbeiten" können die Angaben zum Auftragskopf in mehreren Registern eingegeben werden. Auch die Angaben zu den einzelnen Positionen können über Register erfolgen.
Diese Art der Eingabe wird ausschließlich erreicht durch:
  • INI-Einträge (in Sektion [REPLACECGW] für alle AUF435_R...-Dialoge),
  • einen neuen Rahmendialog (AUF435R.CGW)
  • und vor allem durch die Einträge in dieser Sektion (über AUF435.SDF)
Ein einfacheres Beispiel ist die Eingabe der beiden Selektionsfenster in "Auftragsbestand auswerten" (436). Hier wird die Eingabe über Register nur erreicht durch:
  • einen neuen Rahmendialog (AUF436R.CGW)
  • und vor allem durch die Einträge in dieser Sektion (über AUF436.SDF)
Besonderheiten für 731:
Fast das Programm "731 Einkaufsvorgänge bearbeiten" gibt es einige Abweichungen vom Standard, die im Steckbrief EKA731.PDF (Kapitel "Besonderheit für Registertechnik") beschrieben sind.
Zusammenhänge
Die Angaben in dieser Sektion erlauben die Integration des betroffenen Dialogs in einen anderen Dialog (Masterframe). Das heißt, der Inhalt des Dialogs wird zu einem Bestandteil eines übergeordneten Dialogs - der Dialoginhalt wird in den Patchcontainer (siehe unten) des Masterframes kopiert. Der übergeordnete Dialog wird beim Start des betroffenen Dialogs automatisch gestartet, sofern dieser noch nicht sichtbar ist. Die Sektion [GuiFramePatch] muss dazu direkt bei den Dialog-SibDef-Angaben des zu integrierenden Dialogs hinterlegt werden.
Die Stelle, an die der Inhalt des betroffenen Dialogs integriert werden soll, muss im Masterframe durch einen leeren Container mit einer eindeutigen Grit-ID definiert werden. Die ID dieses Containers wird als PatchControlID in der Sektion [GuiFramePatch] hinterlegt.
In einen Masterframe können mehrere Dialoge integriert werden (simultan oder im Wechsel). Der gleiche Masterframe kann somit in mehreren zu integrierenden Dialogen angegeben werden.
Um unterschiedliche Dialoge im Wechsel an die gleiche Stelle des Masterframes zu integrieren, wird bei den Dialogen die gleiche PatchControlID des Masterframes angegeben. Sobald dann zur Laufzeit einer der Dialoge gestartet (sichtbar) wird, parkt das System den ggf. zuvor an der gleichen Stelle angezeigten Dialoginhalt. Um mehrere Dialoge simultan im gleichen Masterframe anzuzeigen, muss für jeden Dialog ein eigener Container (PatchControlID) im Masterframe vorhanden sein. Diese Container können durchaus auch auf den Seiten eines im Masterframe enthaltenen Registers liegen. Das System aktiviert dann beim Starten (sichtbar machen) eines derartigen Dialogs die zugehörige Registerseite.
Das infra-Programm, das einen zu integrierenden Dialog startet oder anzeigt, bekommt davon übrigens nichts mit - intern wird der Inhalt eines Patchcontainers weiter als eigenständiger Dialog verwaltet. Alle Eingaben und Aktionen werden dem Programm so vermittelt, als würden sie im ursprünglichen (nicht gepatchten) Dialog stattfinden.
 
Hinweis:
Ein Masterframe kann ebenfalls in einen weiteren Masterframe integriert (gepatcht) werden. Dazu muss in den SibDef-Angaben des Masterframes eine Sektion [GuiFramePatch] mit Verweis auf einen anderen Masterframe enthalten sein.
 
Vorgehensweise am Beispiel von AUF435
Alle bisherigen Dialoge bleiben erhalten. Die Daten des Anwahlfensters, Kopfdaten, Zeilenbereich und Bearbeitungsfenster / Detailbereich sollen in einem großen Fenster gleichzeitig sichtbar sein. Dies wird mit Hilfe von Bereichen und Registern realisiert.
  • Basis-Dialog (AUF435R.cgw) neu erstellen
    Diese Datei beinhaltet einen Masterframe-Dialog (AUF435_MAIN), der in zwei Container (Patchcontainer) unterteilt ist:
  • AUF435HEAD (oberer Patchcontainer mit Kopfdaten)
  • AUF435TABS (unterer Patchcontainer mit Positionsdaten)
    Die Einbindung der ehemaligen Dialoge erfolgt über Einträge in der Datei AUF435.SDF (siehe dazu Beschreibung der Einträge in dieser Sektion ([GuiFramePatch])).
    Im Originaldialog des Zeilenfensters (AUF435_R435_1 in der Datei AUF435.CGW) sind bislang noch die zugehörigen Kopfdaten sowie die Hinweiszeile enthalten.
    Dies entspricht nicht dem gewünschten Layout. Deshalb muss dieser Dialog in die neue Datei AUF435R.CGW ohne die ungeliebten Elemente eingebunden werden.
    Der Dialog ist somit in beiden CGW-Dateien vorhanden.
    Damit der geänderte Dialoge verwendet wird, muss ein entsprechender REPLACECGW-Eintrag je Dialog in der SIBPPS.INI-Datei eingefügt werden:
    [REPLACECGW]
    AUF435,AUF435_R435_1=AUF435R,AUF435R_R435_1
  • Zeilen-Dialoge einbinden
    Die Zeilendialoge werden im Masterframe-Dialog als Register im Patchcontainer für Positionsdaten (z.B. AUF435TABS) eingebaut.
    Dazu existiert je Zeilentyp ein Basisdialog (z.B. AUF435_POS_K in AUF435R.CGW).
    Dieser Basisdialog wird abhängig vom zu bearbeitenden Zeilentyp in den Patchcontainer für Positionsdaten des Masterframes geladen.
    Über die PatchFrame-Technik werden die Zeilendialoge auf die Registerseiten des Zeilen-Basisdialogs geladen (z.B. AUF435_POS_K_1, AUF435_POS_K_1, etc.).
    Die Verbindung zwischen herkömmlichen Zeilendialogen und Registern wird über Einträge in der SDF-Datei hergestellt (siehe unten).
  • Trick für Registerwechsel
    In den großen Basis-Dialogen (Behälter für Kopf und Zeilenfenster) muss eine kleine Schaltfläche mit der ID "_RejectFocus_" versteckt sein,
    damit Grit beim Registerwechsel keine Probleme bekommt und in einer Endlosschleife versinkt.
    Ursache:
    Beim Wechsel auf eine andere Registerseite versucht GRIT auf dieser Seite dem ersten eingabefähigen Objekt den Eingabefokus aufzuzwingen.
    Wenn aber auf der Registerseite kein fokussierbares Objekt liegt, versucht GRIT auf das nächste Register mit einem eingabefähigen Objekt zu wechseln.
Beschreibung der Einstellungen
 
MasterFrame = CGW-Name, DialogID
Hier wird der Dialog angegeben, der den aktuellen Dialog aufnehmen soll. Der Masterframe wird automatisch gestartet, sobald der aktuelle Dialog angezeigt werden soll. Mit dem Schlüssel "PatchControlID" muss angegeben werden, auf welchen Container im Masterframe der Inhalt des aktuellen Dialogs gepatcht werden soll. Der Container kann auch auf einer Registerseite eines Registers im Masterframe liegen. Das entsprechende Register wird automatisch sichtbar gemacht, wenn der aktuelle Dialog angezeigt werden soll.
PatchControlID = ControlID
Hier wird die GRITID des Containers im Masterframe (siehe Schlüssel "Masterframe") angegeben, auf den der Inhalt des aktuellen Dialogs gepatcht werden soll. Der angegebene Container kann auch auf einer Registerseite eines im Masterframe enthaltenen Registers liegen. Das entsprechende Register wird automatisch sichtbar gemacht, wenn der aktuelle Dialog angezeigt werden soll.
PropertyControlID = ControlID
Dieser Eintrag kommt bei der Anzeige von Detailinformationen zu einer Positionszeile in einem Bearbeitungsprogramm mit Zeilenfenster zum Einsatz. Hier wird hinterlegt, welcher Container zur Anzeige der Detailinformationen (Positionsdialoge) dienen soll. Dieser Container muss als Patchcontainer (PatchControlID) bei den Positionsbearbeitungsfenstern hinterlegt sein. Die Angabe "PropertyControlID" muss bei dem Container hinterlegt sein, auf dem zur Laufzeit die Positionszeilen (Zeilenfenster) abgebildet werden.
PatchOnCreate = CGW-Name,DialogID
Mit dieser Angabe kann der Inhalt eines Containers, der als Patchcontainer für einen anderen Dialog dienen soll, mit dem Inhalt eines Dialogs initialisiert werden. D.h. bei der Anzeige des Dialogs, in dem ein Container mit "PatchOnCreate" enthalten ist, wird der Inhalt des angegeben Dialogs geladen und in diesem Container angezeigt. Eingabefelder und sonstige Controls werden dabei deaktiviert.
Dadurch kann ein Container bereits gefüllt werden, wenn erst im weiteren Verlauf der Programmbedienung der betroffene Container durch einen Patchdialog gefüllt wird.
PatchPageTitle = Text
Befindet sich der Patchcontainer für den aktuellen Dialog auf einer Registerseite, so kann der angezeigte Text der betroffenen Registerseite mit diesem Eintrag geändert werden, sobald der aktuelle Dialog zur Anzeige gebracht wird.
Beispiel:
[GuiFramePatch]
MasterFrame=AUF435R,AUF435_POS_K
PatchControlID=AUF435PROPR1SW
PatchPageTitle=Abruf
MasterFrameTitle = Text
Über diesen Eintrag lässt sich der Fenstertitel des Masterframes beim Einbinden eines Patchdialogs verändern. Dadurch kann der Titel des Masterframes situationsabhängig geändert werden, wenn z.B. der gleiche Masterframe von unterschiedlichen Programmen benutzt wird (z.B. AUF431 und AUF435). Der Fenstertitel wird geändert, sobald der Patchdialog, bei dem dieser Eintrag hinterlegt ist, angezeigt werden soll.
Beispiel:
[GuiFramePatch]
MasterFrame=AUF435R,AUF435_POS_K
PatchControlID=AUF435PROPR1SW
PatchPageTitle=Abruf
ScrollSelectAction = Function
Die hier angegebene Funktionsnummer (siehe Eintrag "Function" in Sektion [MimAction]) wird bei der Anzeige des betroffenen Dialogs als Positionsbearbeitungsdialog notiert. Wird nun im Laufe der Bedienung eine andere Positionszeile im Zeilenfenster selektiert, wird vor dem Zeilenwechsel zunächst die notierte Funktionsnummer an das Programm zurückgegeben. Das ist dann notwendig, wenn es sich bei dem betroffenen Positionsbearbeitungsdialog um ein ehemaliges Zusatzfenster handelt, das jetzt auf einer Registerseite (nicht bei Registerseite 1) im Detailbereich angezeigt wird. Das Programm muss hier vor der Selektion einer neuen Positionszeile vom Schließen des Zusatzfensters informiert werden. In der Regel wird als Function der Wert aus Sektion [MimAction], Eintrag "Function", der Okay-Schaltfläche des betroffenen Zusatzfensters eingetragen.
ChangeMasterAction.Nr = ControlID,Callback,Parameter
Mit diesem Eintrag kann bei der Anzeige des aktuellen Patchdialogs das Verhalten eines Controls (Schaltfläche oder Menüeintrag) im Masterframe geändert werden. Dazu wird die hier angegebene infra-Prozedur (Callback) samt Parameter als Aktion für das Betätigen (Activate) des betroffenen Controls notiert. Das ist dann notwendig, wenn im Masterframe Schaltflächen verwendet werden, deren Betätigung unterschiedliche Aktionen abhängig vom jeweils angezeigten Patchdialog auslösen müssen.
Sind mehrere Einträge dieser Art notwendig, müssen diese im Schlüssel durch unterschiedliche eindeutige Nummer (.Nr) unterschieden werden.
Beispiel:
In PDV121 werden beim Abbrechen eines Positionsbearbeitungsfensters für eine S-Zeile abhängig vom Modus "Erfassen" oder "Ändern" unterschiedliche Funktionsnummern (100 oder 55) an das Programm zurückgegeben. Da sich die Abbrechen-Schaltfläche der Positionsbearbeitungsregister im gemeinsamen übergeordneten Masterframe (PDV121_POS_S) befindet, muss die Funktionsnummer der Schaltfläche (PB_POS_CANCEL) abhängig vom Patchdialog angepasst werden:
[PDV121_5##GuiFramePatch]
MasterFrame=PDV121R,PDV121_POS_S
PatchControlID=PDV121PROPR1SW
ChangeMasterAction.1=PB_POS_CANCEL,CBgMimTriggerMimAction,F.100
[PDV121_13##GuiFramePatch]
MasterFrame=PDV121R,PDV121_POS_S
PatchControlID=PDV121PROPR1SW
ChangeMasterAction.1=PB_POS_CANCEL,CBgMimTriggerMimAction,F.55
ChangeMimAction.Nr = ControlID, ActionID
Dieser Eintrag erlaubt das Verändern einer Aktion für ein Control (Schaltfläche oder Menu) im aktuellen Dialog. Dadurch werden Verhaltensänderungen erlaubt, ohne den betreffenden Dialog verändern zu müssen (der Eintrag kann z.B. in einer SDF-Datei hinterlegt werden).
Als ActionID kann eine Funktionsnummer (F.Function) oder eine F3-Funktionsnummer (F3.Function) angegeben werden (siehe Sektion [MimAction]).
Sind mehrere Einträge dieser Art notwendig, müssen diese im Schlüssel durch unterschiedliche eindeutige Nummer (.Nr) unterschieden werden.
Beispiel:
In AUF435 soll bei Anzeige des Kopf-Patchdialogs die Okay-Schaltfläche mit der Aktion zum direkten Wechsel in den Positionsbereich Siehe Sektion [MimAction], Angabe Function=108) belegt werden:
[AUF435_2##GuiFramePatch]
MasterFrame=AUF435R,AUF435_MAIN
PatchControlID=AUF435HEAD
ChangeMimAction.1=PB_OKAY,F.108
HideControl.Nr = ControlID
Beim Anzeigen eines Patchdialogs kann das hier angegebene Control des Patchdialogs ausgeblendet werden. Das bietet sich dann an, wenn für ein Control (z.B. eine Schaltfläche) bereits im übergeordneten Masterframe ein Control vorhanden ist. So können z.B. überflüssige Schaltflächen aus Registerseiten entfernt werden.
Die Angabe "HideControl" kann sowohl beim Patchdialog als auch beim Patchcontainer (PatchControlID) des Masterframes hinterlegt werden. Sie gilt dann für alle Patchdialoge, die in diesem Patchcontainer angezeigt werden können.
Sind mehrere Einträge dieser Art notwendig, müssen diese im Schlüssel durch unterschiedliche eindeutige Nummer (.Nr) unterschieden werden.
AllowOnHide.Nr = ControlID, ActionID
Durch diesen Eintrag wird das angegebene Control (z.B. ein Eingabefeld) des Patchdialogs beim Verlassen bzw. deaktivieren des Patchdialogs nicht gesperrt, so dass es weiterhin für Benutzerinteraktionen sensibel ist, auch wenn das betroffene Programm eine Eingabe in diesem Dialog eigentlich nicht zulässt.
Wechselt der Anwender den Eingabefokus (z.B. durch Mausklick) in dieses Feld, sendet das System die als ActionID angegebene Aktion an das aktive Programm (den aktiven Dialog). Als ActionID kann eine Funktionsnummer (F.Function) oder eine F3-Funktionsnummer (F3.Function) angegeben werden (siehe Sektion [MimAction]).
Dies ermöglicht dem Anwender z.B. den Wechsel in den Kopfbereich eines Masterframes und die Anwahl z.B. einer neuen Stückliste, ohne zuvor eine Abbrechen-Schaltfläche betätigen zu müssen. Voraussetzung für den Einsatz dieser Erleichterung, ist eine im Programm bekannte Aktion (Function oder F3-Function), die in jedem Dialog einen Wechsel in den Kopfbereich zulässt.
Sind mehrere Einträge dieser Art notwendig, müssen diese im Schlüssel durch unterschiedliche eindeutige Nummer (.Nr) unterschieden werden.
Beispiel:
[PDV121_1##GuiFramePatch]
MasterFrame=PDV121R,PDV121_MAIN
PatchControlID=PDV121HEAD
AllowOnHide.1=PDV121_1_F1,F.106
FromPatchID_RegisterContainerID={Makroanweisung[;]Makroanweisung…}
Werden in einem Masterframe mehrere Patchdialoge in ein Register auf unterschiedlichen Registerseiten integriert, ist es notwendig dem Programm mitzuteilen, was passieren soll, wenn der Benutzer einen Registerwechsel vornimmt und somit den aktuell angezeigten Patchdialog beendet und zu einem anderen Patchdialog wechselt.
Dieser Eintrag führt abhängig von der zuvor angezeigten Registerseite die angegebenen Makroanweisungen aus. Bestimmte Makroanweisungen müssen dabei erst vom Programm verarbeitet werden, bevor es für weitere Aktionen bereit ist. Durch ein Semikolon in der Anweisungsfolge wird die Abarbeitung der Makros solange unterbunden, bis das Programm die vorherige Anweisung verarbeitet hat. So führt z.B. die Makroanweisung "MimTriggerMimAction" dazu, dass dem Programm ein sogenannter Actioncode (ActionID) übermittelt wird. Um die Aktion, die sich hinter der jeweils übermittelten ActionID verbirgt, ausführen zu können, muss dem Programm durch eine Unterbrechung der Anweisungsfolge - mittels Semikolon - Gelegenheit dazu gegeben werden.
Mehrere durch Semikolon getrennte Makroanweisungen sind unter Umständen dann notwendig, wenn ein Registerwechsel über mehrere Registerseiten erfolgt und dem Programm die Bedienungsfolge übermittelt werden muss, die zu dem gewünschten Dialog (Patchdialog der Registerseite) führt.
Die Einträge müssen auf dem obersten Container einer Registerseite hinterlegt werden. Im Schlüssel wird als RegisterContainerID die GRITID des obersten Containers der Ursprungsregisterseite angegeben.
Durch die Makroanweisung "MimTriggerMimAction" kann eine Funktionsnummer (F.Function) oder eine F3-Funktionsnummer (F3.Function) an das Programm übermittel werden (siehe Sektion [MimAction]). Vor der eigentlichen Aktion wird dabei eine Feldprüfung des zuletzt verlassenen Feldes ausgeführt. Um dies bei Bedarf zu verhindern, kann hinter der Funktionsnummer "No" angegeben werden (also z.B. "MimTriggerMimAction(F.109,No)").
Beispiele
Hier die Angaben des ersten Registers des Positionsdetailfensters einer K-Zeile in AUF435:
FromPatchID_AUF435PROPR2={ MimTriggerMimAction(F.109) }
FromPatchID_AUF435PROPR3={ MimTriggerMimAction(F.109) }
FromPatchID_AUF435PROPR4={ MimTriggerMimAction(F.109) }
Insgesamt existieren hier 4 Registerseiten. Es muss für jede mögliche Ursprungsregisterseite ein eigener Eintrag für den Wechsel zum Register 1 existieren. Hier kann von jeder Registerseite aus das erste Register über den Funktionscode 109 erreicht werden. Der Code entspricht der Okay-Schaltfläche der Positionszusatzfenster, die auf die entsprechenden Registerseiten gepatcht werden.
Ein Wechsel zwischen Positionszusatzfenstern über mehrere Registerseiten setzt i.d.R. eine Reihe von Bedienungsaktionen voraus, die nur über eine kleine Makro-Anweisungsfolge formuliert werden kann.
Hier die Angaben des zweiten Registers des Positionsdetailfensters einer K-Zeile in AUF435:
FromPatchID_AUF435PROPR1={ MimTriggerMimAction(F.102) }
FromPatchID_AUF435PROPR3={ MimTriggerMimAction(F.50) }
FromPatchID_AUF435PROPR4={ MimTriggerMimAction(F.50); MimTriggerMimAction(F.50); }
Beim Wechsel von Register 4 auf Register 2 muss zunächst über den Funktionscode 50 (entspricht der "Function-Angabe" in Sektion [MimAction], also der Zurück-Schaltfläche) das zur vierten Registerseite gehörige Zusatzfenster geschlossen und das zur dritten Registerseite gehörige Zusatzfenster geöffnet werden. Danach muss wiederum über den Funktionscode 50 vom dritten Zusatzfenster zum zweiten Zusatzfenster gewechselt werden.