top of page

edi Element als Detail-Element mit Parametern aufrufen / Call an edi element as a detail element with parameters

9.0.x

Sonntag, 20. April 2025

Deutsch

Hintergrund/Anforderung

Beispielsituation

Lösungsansatz über Kontextmenü und Makro-Ausdruck

Verwendung von Dialog-Variablen in Datenquellen

Dialog-Variablen bei der Anlage eines neuen Datensatzes berücksichtigen

Bereits geöffnetes Detail-Element aus Master-Element aktualisieren



Deutsch

Hintergrund/Anforderung

Sehr häufig kommt es in der Praxis vor , dass man aus einem vorhandenen UX/UI-Element , z.B. einer Liste oder einer vorhandenen edi-Bearbeitung ein untergeordnetes edi-Element als Detail-Element öffnen möchte.

⚠️Dieses untergeordnete Detail-Element soll dann ausschließlich die Datensätze des zuvor ausgewählten Master-Datensatzes des vorher geöffneten Elements anzeigen.


Beispielsituation

Im vorliegenden Beispiel gibt es ein UX/UI-Element , welches zunächst als Datensatz an eine Tabelle gebunden ist.

D.h. es wurde eine einfache Stammdaten-Maske mit einer Liste als Navigationselement und einem edi-Element mit Typ "Stammdaten-Modus basierend auf Datensätzen" geschaffen.


👆🏻Tipp: Für den Bau von Tabellen, die als Datensatz im AppDesigner verwendet werden sollen , empfiehlt sich die Einhaltung gewisser Primärschlüssel-Regeln. Details siehe hier:

https://www.officium-inservio.com/sage-100-appdesigner/writablelists1#viewer-oa2th115954


Zweck dieses "Master"-edi-Elements als Stammdaten-Erfassung ist es zunächst , eine einfache Liste von Sätzen mit möglichen Feld-Definitionen zu zeigen.

Jeder Feld-Definition-Satz kann dann x untergeordnete Datenfelder enthalten.

D.h. der Anwender ist in der Lage , zunächst in diesem "Master"-Stammdaten-Fenster alle vorhandenen definierten Sätze von Feld-Definitionen anzuzeigen und zu bearbeiten.


Beispiel Ansicht des "Master"-Elements - wenn der Anwender den in Blau markierten Schalter "Datenfelder" anklickt , dann soll die Detail-Stammdaten-Bearbeitung aller Felder aufgerufen werden , die zu dem ausgewählten Datensatz "DATEV_EXTF_700_DATA" passen!
Beispiel Ansicht des "Master"-Elements - wenn der Anwender den in Blau markierten Schalter "Datenfelder" anklickt , dann soll die Detail-Stammdaten-Bearbeitung aller Felder aufgerufen werden , die zu dem ausgewählten Datensatz "DATEV_EXTF_700_DATA" passen!

Im Fenster sieht man sehr gut , dass derzeit zwei Sätze von Feld-Definitionen existieren. Inhaltlich geht es dabei um eine flexible Definition von Importen auf der Basis von Textdaten - in dem Fall um einen DATEV EXTF-Buchungsstapel-Import.

Eine solche DATEV-Datei besteht innerhalb einer Datei aus zwei unterschiedlichen Feldstrukturen.


Wenn der Anwender nun z.B. die im Screenshot zu sehende Definition "DATEV_EXTF_700_DATA" selektiert hat , dann stellt sich die Frage wie man zu diesem selektierten Datensatz am schnellsten ein weiteres edi-Stammdaten-Element aufrufen kann , welches dann ausschließlich diejenigen Datensätze filtert , die zu diesem "Master"-Stammdatensatz "DATEV_EXTF_700_DATA" gehören.

Beispiel Ansicht des "Detail"-edi-Elements - dieses zeigt nun ausschließlich Datensätze , die zu dem im "Master" edi-Element ausgewählten Datensatz "DATEV_EXTF_700_DATA" passen!
Beispiel Ansicht des "Detail"-edi-Elements - dieses zeigt nun ausschließlich Datensätze , die zu dem im "Master" edi-Element ausgewählten Datensatz "DATEV_EXTF_700_DATA" passen!

Lösungsansatz über Kontextmenü und Makro-Ausdruck

Ein sehr einfacher Weg ist über das an das edi-Element gebundene Kontextmenü und einen Makro-Ausdruck in dem dort vorhandenen Kontextmenüeintrag "Datenfelder".

Kontextmenü-Eintrag
Kontextmenü-Eintrag

Der Menüeintrag verfügt über folgende Eigenschaften:

Details des Menü-Eintrages
Details des Menü-Eintrages

Wichtig ist , dass der Aufruf nur bei einer "Einzelselektion" sinnvoll ist und natürlich nur dann , wenn überhaupt ein gültiger Datensatz vom Anwender in der Liste ausgewählt wurde (die Liste ist das Navigationselements des edi).

Dann erfolgt die Makro-Definition.

Makro-Details
Makro-Details

Es ist gut zu sehen , dass das "untergeordnete" Detail-edi "ediPreImpTxtBdDataFldSetFlds" mit Parametern aufgerufen wird.

⚠️Allerdings nicht in der i.d.R. üblichen "Parameter 2"-Übergabe , sonder in der "Parameter 3"-Übergabe!

Dies ist wichtig , da es hierbei nicht um die Vorbelegung der Primärschlüssel 1-x des edi-Elements geht (das wäre "Parameter 2") , sondern Ziel ist es , an dieser Stelle die Schlüssel des derzeit im "Master"-edi-Element gewählten Haupt-Datensatzes als "Dialog-Variable" an das "Detail"-edi-Element zu übergeben.


Dazu fügt man in "Parameter 3" entsprechend die Parameter in folgender Syntax ein:

__pSAGImportFldSetId:=[ImportFldSetId];...

Es ist gut zu sehen , dass - sehr wichtig - zwei(!) Unterstriche benutzt werden , um die Variable zu definieren. Dadurch wird diese zu einer "Dialog-Variable" , die dann auch in der zugerundeliegenden Datenquelle des Navigationselements verwendet werden kann!


Dies geht auch eindeutig aus der Dokumentation des AppDesigners hervor.

Regel zur Verwendung von Dialog-Variablen
Regel zur Verwendung von Dialog-Variablen

Verwendung von Dialog-Variablen in Datenquellen

Nun stellt sich die Frage , wie die Definition der Datenquelle des "untergeordneten" Detail-edi-Elements aussehen muss.

Die Datenquelle des Navigationselements der Liste des "Detail"-edi ist an eine SQL-View gebunden und wird mit dem Alias "FS" abgekürzt.
Die Datenquelle des Navigationselements der Liste des "Detail"-edi ist an eine SQL-View gebunden und wird mit dem Alias "FS" abgekürzt.
In der Where-Clause wird dann entsprechend mit zwei(!) Unterstrichen die Dialog-Variable abgefragt. Die Dialog-Variable "__pSAGImportFldSetId"wurde weiter oben im Makro-Ausdruck des Kontextmenüs bei dem "OpenDataEditPart"-Aufruf definiert.
In der Where-Clause wird dann entsprechend mit zwei(!) Unterstrichen die Dialog-Variable abgefragt. Die Dialog-Variable "__pSAGImportFldSetId"wurde weiter oben im Makro-Ausdruck des Kontextmenüs bei dem "OpenDataEditPart"-Aufruf definiert.

Die Selektionslogik ist wie folgt:

FS.ImportFldSetId <> 0
AND -1 = CFN_IfParameterExists('__pSAGImportFldSetId','" AND FS.ImportFldSetId = CFN_Parameter(''__pSAGImportFldSetId'') "')

Es kommt das Sage-typische "CFN_IfParameterExists" in Kombination mit "CFN_Parameter" zum Einsatz.

Dieses etwas "merkwürdig" ausschauende Konstrukt stellt sicher , dass dieser Parameter ausschließlich dann abgefragt wird , wenn er auch als Dialog-Variable vorhanden ist.


Dialog-Variablen bei der Anlage eines neuen Datensatzes berücksichtigen

Im vorliegenden Fall handelt es sich bei dem "Detail"-edi-Element um eine Bindung an einen Datensatz zur Stammdatenpflege.

Der Anwender kann neue Datensätze anlegen.

Dabei muss natürlich die Referenzintegrität zu dem "Master"-edi-Element-Datensatz gewährleistet werden.

Auch dabei können ebenfalls die Dialog-Variablen verwendet werden.

Und zwar im Client-seitigen Makro-Handler des Datensatzes.

Einstiegspunkt zur Vorgabe der Schlüssel ist das "Before Update"-Ereignis des Datensatzes.
Einstiegspunkt zur Vorgabe der Schlüssel ist das "Before Update"-Ereignis des Datensatzes.
Ein Client-seitiges Makro wird verwendet , um die Dialog-Variablen in die Felder zu überführen!
Ein Client-seitiges Makro wird verwendet , um die Dialog-Variablen in die Felder zu überführen!

In diesem Makro-Code setzt man entsprechend die Felder für den neu zu erstellenden Detail-Datensatz anhand der vorhandenen Dialog-Variablen.

Somit wird der neue Datensatz , den der Anwender erstellt , korrekt dem übergeordneten Master-Datensatz zugewiesen.



Bereits geöffnetes Detail-Element aus Master-Element aktualisieren

Wenn das "Detail"-edi-Element bereits zur Anzeige geöffnet ist und der Anwender wechselt in das "Master"-edi-Element zurück , um dort erneut die Details aufzurufen , dann wird das bereits geöffnete "Detail"-Element nicht automatisch von Sage aktualisiert.


Natürlich könnte man einfach in dem ursprünglichen Makro , welches das "Detail"-edi-Element aufruft , nach dem Detail-Aufruf das Haupt-Element mit "CloseDialog" schließen.

Das ist aber nicht sehr elegant!

Besser ist es , mit der Makro-Funktion "SendRefreshNotification" (AktualisierungsnachrichtSenden) eine Aktualisierungsanweisung an das eventuell bereits geöffnete "Detail"-Element zu senden.

Mittels "SendRefreshNotification" kann man die UX/UI-Shell instruieren , alle UX/UI-Elemente zu aktualisieren , die den hier genannten Text "SAGPreImpTxtSetFlds" in der Liste der "Refresh Notifications" als ID definiert haben - dies ist eine entsprechende Eigenschaft im UX/UI-Element , welches aktualisiert werden soll - in diesem Fall die Liste des Navigationselements.
Mittels "SendRefreshNotification" kann man die UX/UI-Shell instruieren , alle UX/UI-Elemente zu aktualisieren , die den hier genannten Text "SAGPreImpTxtSetFlds" in der Liste der "Refresh Notifications" als ID definiert haben - dies ist eine entsprechende Eigenschaft im UX/UI-Element , welches aktualisiert werden soll - in diesem Fall die Liste des Navigationselements.
Im Listen-Element , welches als Navigationselement des "Detail"-edi arbeitet , werden die "Refresh Notifications" definiert - diese IDs stehen dann für "SendRefreshNotification"-Aufrufe über die UX/UI-Shell der Anwendung zur Verfügung.
Im Listen-Element , welches als Navigationselement des "Detail"-edi arbeitet , werden die "Refresh Notifications" definiert - diese IDs stehen dann für "SendRefreshNotification"-Aufrufe über die UX/UI-Shell der Anwendung zur Verfügung.
Im Listen-Element , welches als Navigationselement des "Detail"-edi arbeitet , muss entsprechend die ID hinterlegt sein , die im o.g. Makro bei "SendRefreshNotification" als String-Konstante übergeben wird!
Im Listen-Element , welches als Navigationselement des "Detail"-edi arbeitet , muss entsprechend die ID hinterlegt sein , die im o.g. Makro bei "SendRefreshNotification" als String-Konstante übergeben wird!

👆🏻Tipp: Im Legacy-Code MS-Access steht die Funktion "gbSendAuskunftNotification" zur Verfügung , um Elemente sogar aus dem Legacy-Client heraus zu aktualisieren.



bottom of page