Erstellung eines Stammdatendialoges

Um ein funktionalen Stammdatendialog zu erstellen benötigen Sie mindestens diese Metadatenobjekte:

• Datenquelle
• Listen-Element
• Kontextmenü
• Datensatz
• Daten-Edit-Element

Die Zusammenhänge der einzelnen Metadatenobjekte eines Stammdatendialoges veranschaulicht das nachfolgende Bild.

Die Basis eines Stammdatendialoges ist der Datensatz. Das Laden, Verwerfen von Änderungen und Speichern eines Datensatzes übernimmt das System. Lediglich die Neuanlage und das Löschen eines Datensatzes müssen mittels Funktionsaufrufe, welche durch einen Kontextmenüeintrag ausgeführt werden, in den Metadaten definiert werden.

Das Laden eines Datensatzes erfolgt durch Selektion eines Datensatzes im Navigationselement. Dabei gilt folgender Zusammenhang: Der Schlüssel (also die einzelnen Felder) der zugrundeliegende Tabelle muss in den Schlüsselfelder der Datenquelle des Navigationselementes hinterlegt sein. Dabei ist die gleiche Reihenfolge zu verwenden, wie in der Definition der Schlüsselfelder des Datensatzes. Das Feld der Mandantennummer wird dabei nicht berücksichtigt. Durch die Angabe des Mandantenfeldes im Datensatz (Eigenschaft "Mandantenfeld Tabelle1/2") fügt das System der Sage 100 die Mandantennummer dem Schlüssel hinzu.

Beispiel: Themenverwaltung

Beginnen wir mit der Basis und legen den Datensatz „recProjektthemen“ an. Legen Sie dazu unter „Daten/ Datensätze“ die Metadatengruppe „Projektsteuerung“ und mit der Option „Tabelle importieren“ (Tabelle BPKProjektthemen) den Datensatz (alle Felder übernehmen) an. Hinterlegen Sie in der Eigenschaft „Sortierung“ das Feld „Thema“ (aufsteigend). Alle anderen Felder sind durch den Tabellenimport bereits richtig gesetzt.

Legen sie die neue Datenquelle „dtsProjektthemen“ an und selektieren wie oben im Assistenten die Option "Tabelle importieren". Im Dialog "Tabelle importieren" wählen sie die Tabelle "BPKProjektthemen" aus. Auch hier wird das Schlüsselfeld 1 korrekt gefüllt (das Feld „Thema“ ist in der Tabelle BPKProjektthemen als Schlüsselfeld definiert). Ändern Sie die Eigenschaft „Priorität“ des Feldes „Thema“ auf „1“ und den „Titel“ des Feldes „IstExternesThema“ in „Externes Thema“.

Legen Sie unter „Oberfläche/ Elemente/ Projektsteuerung“ das Listen-Element „lstProjektthemen“ mit dem Assistenten „Datenquelle zuordnen“ („dtsProjektthemen)“ an. Ordnen Sie die Felder („Spaltenummer“) nach „Thema“, „Bezeichnung“, „Gruppe“ und „IstExternerTermin“. Aktivieren Sie unter der Eigenschaftengruppe "Lizenzierung" die Option "für Wawi?".

Legen Sie das Kontextmenü „Projektthemen“ an. Legen Sie folgende Kontextmenüeinträge an:

• „Funktionsname” = „Neu”
  • „Funktionstitel“ und „Funktionskurztitel“ = „Neu“
  • „Tastenkürzel” = „Strg+N” (Standard in den Sage-Lösungen)
  • „Position in Sortierung“ = „1“
  • „Schaltflächenposition“ = „1“
  • „Funktionsaufruf“ = „DatensatzNeu.Sage.System“
  • „für Wawi?“ aktivieren
• „Funktionsname” = „Loeschen”
  • „Funktionstitel“ und „Funktionskurztitel“ = „Löschen“
  • „Position in Sortierung“ = „2“
  • „Schaltflächenposition“ = „2“
  • „Funktionsaufruf“ = „DatensatzLoeschen.Sage.System“
  • „für Wawi?“ aktivieren

Die Aktion "Neu" kann direkt nach dem Öffnen des Dialoges, also ohne Auswahl eines Datensatzes, oder nach der Auswahl eines Datensatzes, oder nach dem Bearbeiten und Speichern eines neuen/alten Datensatzes durchgeführt werden. Die Aktion "Löschen" kann nur auf einen bestehenden Datensatz ausgeführt werden. Es wäre daher auch nur konsequent, wenn der Menüeintrag "Löschen" auch nur dann aktivierbar ist.

Ein Daten-Edit-Dialog kennt zwei Zustände:

• Neuanlage
• Bearbeitung eines bestehenden Datensatzes

Diese Stati können abgefragt werden. Dafür gibt es die Variable _DialogState. Die Werte sind "Create" und "Edit". 

Für das Freischalten eines Kontextmenüeintrags gibt es diverse Möglichkeiten (siehe Kontextmenüs). Tragen Sie in der Eigenschaft "Festlegung Aktivierung durch Feld" des Kontextmenüeintrages "Loeschen" den Ausdruck "[_DialogState]="Edit"" ein.

Legen Sie unter „Oberfläche/ Elemente/ Projektsteuerung“ das Daten-Edit-Element „ediProjektthemen“ an.

Das Daten-Edit-Element ist das UI-Element zum Bearbeiten von Daten, also nicht zwingend nur für Stammdatendialoge einzusetzen. Daher muss in der Eigenschaft „Verwendungszweck“ eben dieser eingestellt werden. Wir wollen das Daten-Edit-Element als „Stammdatendialog für einen Datensatz“ verwenden und stellen daher diese Eigenschaft entsprechend ein. Ordnen Sie den Datensatz „recProjektthemen“, das Kontextmenü „Projektthemen“ und das Navigationselment „lstProjektthemen“ zu.

Auch diesem Element („ediProjektthemen“) muss die Definiton der Schlüsselfelder bekannt gegeben werden. Und zwar wird hier die Nummer des Schlüsselfeldes der Datenquelle des Navigationselementes eingetragen. In unserem Fall tragen wir in der Eigenschaft „Primärschlüssel 1 für Datensatz“ den Wert „1“ ein.

Stamdaten- oder Erfassungsdialoge können recht komplex sein. Eine Unterteilung und Gruppierung von Daten ist daher in den meisten Fällen von Nöten. Diese Einteilung erfolgt durch Definition von Registern und innerhalb eines Registers von Feldgruppen. Diese Hinterlegung (Registaer und Feldgruppen) muss aber in allen Fällen erfolgen, also auch dann, wenn man nur wie in diesem Beispiel 4 Felder zur Anzeige/Bearbeitung bereit stellt. Bei der Darstellung (Rendering) in der Applikation entscheidet das System, ob Register/Feldgruppen angezeigt werden. Ist nur eine Registerkarte aktiv, wird keine Registerkarte angezeigt. Ist nur eine Feldgruppe auf einer Registerkarte aktiv, dann wird keine Gruppierung (also Überschrift und Trennlinie) angezeigt. Aktiv kann hier zwei Zustände bedeuten:

• Es ist nur eine Registerkarte definiert worden
• Es sind alle Felder einer oder mehrerer Register auf unsichtbar gesetzt worden (durch Lizenzierung oder Makros möglich), so dass nur eine Registerkarte "aktiv" ist.
• Es ist nur eine Feldgruppe definiert worden
• Es sind alle Felder einer oder mehrerer Feldgruppen auf unsichtbar gesetzt worden (durch Lizenzierung oder Makros möglich), so dass nur eine Feldgruppe "aktiv" ist.

Selektieren Sie das Daten-Edit-Element "ediProjektthemen" und wählen Sie aus dem Kontextmenü (rechte Maustaste) "Neue Data-Edit-Element-Registerkarte" aus. Geben Sie als Name und Titel "Projektthemen" ein. Selektieren Sie die neue Registerkarte und wählen Sie aus dem Kontextmenü (rechte Maustaste) "Neue Data-Edit-Element-Gruppe" aus. Geben Sie als Name und Titel "Projektthemen" ein. Selektieren Sie die neue Element-Gruppe und wählen Sie aus dem Kontextmenü (rechte Maustaste) "Felder importieren" aus.

Aktivieren Sie für Testzwecke die Lizenzoption „im Regiezentrum verfügbar?“ und rufen den Stammdatendialog unter „Stammdaten/ Weitere Stammdaten“ auf. Sie können alle für einen Datensatz benötigten Aktionen durchführen. Das wird durch die Bekanntgabe der Schlüsselfelder in allen beteiligten Elementen ermöglicht.

Frage: Basieren Daten, die in der Liste und/oder des Daten-Edit-Elementes angezeigt werden, auf Daten, die in der Mandanten-Datenbank mit Werten gespeichert werden, die nicht der gewünschten Anzeige entsprechen (in unserem Beispiel „Gruppe“ und „IstExternesThema“)?

• Antwort ist Ja: Sie benötigen zusätzlich String Ressourcen.
• Antwort ist Nein: Daten werden weiterhin als Integerwerte bzw. Checkboxen angezeigt

Analog dem Beispiel für die Auskünfte werden wir die Strings „Ja“ und „Nein“ aus dem Standard verwenden. Die Strings für das Feld „Gruppe“ müssen wir anlegen.

Bei der Beschreibung des Beispiels, sind die Bedeutungen der Intergerwerte aufgeführt. Legen Sie also folgende Strings an:

Wie bei den Auskünften beschrieben, werden die Strings über den „Datentyp“ = „Indizierter String“ in der Eigenschaft „Datentyp Ergänzung“ zugewiesen. Der Wert in der Spalte „Index“ entspricht dem geschpeicherten Wert. Ändern Sie in der Datenquelle „dtsProjektthemen“ und dem Datensatz „recProjektthemen“ die Felder „Gruppe“ und „IstExternesThema“ entsprechend.

Frage: Soll man auch Daten in der Navigationsliste bearbeiten können?

• Die Antwort ist Ja: Ändern Sie die Eigenschaft „Editiermodus“ des Navigationselementes des Daten-Edit-Elements „ediProjektthemen“ auf „Editierbar mit Detailbereich“.
• Die Antwort ist Nein: Weiter mit Validierungen

Frage: Soll man Daten nur in der Navigationsliste bearbeiten können?

• Die Antwort ist Ja: Ändern Sie die Eigenschaft „Editiermodus“ des Navigationselementes des Daten-Edit-Elements „ediProjektthemen“ auf „Editierbar ohne Detailbereich“.
• Die Antwort ist Nein: Weiter mit Validierungen

Sobald Sie den Editiermodus auf „Editierbar…“ ändern, kann ein Datensatz auch im Navigationselement geändert werden. Sollen auch neue Datensätze angelegt werden, dann kann nur die Einstellung "Editierbar mit Detailbereich" verwendet werden, da ein neuer Datensatz nur im Detailbereich angelegt werden kann. Sollen Felder in der Navigationsliste bearbeitbar sei, ist folgender Zusammenhang zu beachten: ein Feld kann in der Navigationsleiste bearbeitet werden, wenn Feldname und Datentyp von der Datenquelle des Navigationselementes und des Datensatzes identisch sind.

Ferner ist zu beachten: technisch bearbeitet man das Feld des Daten-Edit-Elementes und damit das dahinter liegende Datensatzfeld. Daher werden Eigenschaften des Daten-Edit-Elementes und des Datensatzfeldes (z.B. „Schreibschutz?“) innerhalb der Liste berücksichtigt.

Laut Beispiel soll der Stammdatendialog „ediProjektthemen“ ohne Detailbereich angelegt werden, es sollen aber natürlich auch neue Datensätze angelegt werden können. Stellen Sie also die Eigenschaft „Editiermodus“ auf „Editierbar mit Detailbereich“.

Frage: Müssen Eingaben/Änderungen vor dem Speichern validiert werden?

• Die Antwort ist Ja: Sie brauchen einen Makroaufruf und eine .Net-Assembly, die serverseitig ausgeführt wird.
• Die Antwort ist Nein: Die Erstellung des Stammdatendialoges ist abgeschlossen.

Die Kommunikation zwischen Client und Server erfolgt mittels Übertragung basierend auf einen Protokoll (bei Sage ist es das SData-Protokoll). Diese Übertragungen könnte man abfangen, die Daten ändern und den geänderten Request des Clients weiter an den Server schicken. Somit werden andere (schlimmstenfalls invalide) Daten gespeichert.

Schreibende Metadatenobjekte, sowie zugehörigen UI-Metadatenobjekte führen bei bestimmten Aktionen Ereignisse aus. Beim Ausführen dieser Ereignisse werden Makrobefehle ausgeführt. Man hinterlegt also Makrobefehle bei dem Ereignis, bei dem man beim Ausführen der Aktion eingreifen möchte.

Wir wollen vor dem Speichern des Datensatzes eingreifen. Also können wir nur ein Ereignis des Datensatzes verwenden, da nur dieses Metadatenobjekt zum Server geschickt wird. Bei einem Datensatz gibt es diese Ereignisse:

Die Namen der Ereignisse erklären bereits, bei welcher Aktion Makrobefehle ausgeführt werden können. Man könnte sich allerdings die Frage stellen, warum es kein „Vor Einfügen“ Ereignis gibt. Die Antwort ist, dass das System im Ereignis „Vor Änderung“ die Möglichkeit bietet, abzufragen, ob es sich um einen neuen oder ein geänderten Datensatz handelt (IsRecordInsert()). Außerdem werden einige Ereignisse clientseitig (zuerst) und serverseitig (dannach) ausgeführt. Auch dafür stellt das Sytem eine Möglichkeit der Abfrage (IsRunningOnServer()) zur Verfügung.

Was wir nun noch benötigen ist ein Makrobefehl, der eine serverseitige .Net-DLL aufruft. Dieser Makrobefehl lautet „AufrufenDLL“. Laut Beschreibung in Makro-Funktionalität benötigt der Befehl den Namen der Assembly und den Namen der Klasse, die von „MacroProcessBase“ ableitet. Daher erstellen wir erst die Assembly.

Laut Beispiel sollen vor dem Speichern folgende Punkte geprüft werden:

• Das Feld „Thema“ ist bei gespeicherten Themen nicht mehr änderbar.
• Ein Thema darf nicht gelöscht werden, wenn es bereits in der Projektsteuerung verwendet wird.
• Die Einstellung „Externes Thema“ darf nicht auf „Nein“ umgestellt werden, wenn es bereits Termine mit diesem Thema und einem Eintrag in „Kontakt“ gibt.
• Die Gruppe darf nur mit einer speziellen Berechtigung geändert werden.

Für die Codierung legen wir das Projekt „Sagede.ADID.Projektsteuerung.RealTimeData.dll“ an.

Die Erstellung Ihrer .Net-Assemblies erfolgt natürlich anhand Ihren Vorgaben von Namespace und Styleguide. Da wir aber immer mehr Code anlegen werden, hier kurz der Aufbau unserer Solution.

Um die geforderten Validierungen zu codieren, müssen wir uns in die Ereignisse „Vor Änderung“ und „Vor Löschung“ integrieren. Für beide Ereignisse legen wir jeweils eine Klasse an.

Der Aufruf der Dll muss nun noch in den Ereignissen hinterlegt werden. Dabei können wir die beiden Parameter cancel und cancelMessage mit den lokalen Variablen [_Canceled] und [_CanceledMessage] abfragen. Für die Ausgabe benötigen wir einen String, den wir unter „Grundlagen/ Strings“ wie folgt anlegen:

Wir hinterlegen in den Ereignissen „Vor Änderung“ und „Vor Löschung“ folgende Makros (PartnerId und LösungId entsprechen Ihren Daten):

Ereignis „Vor Änderung“

Ereignis „Vor Löschung“

Damit haben wir erreicht, dass keine invaliden Daten gespeichert werden. Da der Aufruf aus den Ereignissen des Datensatzes erfolgt, ist es auch unerheblich von welchem Client die Daten geschickt werden. Zusätzlich könnte man Validierungen auf dem Client vornehmen, damit der Anwender nicht erst Fehleingaben tätigen kann, um dann beim Speichern eine entsprechende Meldung zu erhalten.

Frage: Soll der Stammdatendialog an definierter Stelle aus dem Regiezentrum aufrufbar sein?

• Die Antwort ist Ja: Sie benötigen einen Eintrag unter „Oberfläche/ Regiezentrum“
• Die Antwort ist Nein: Die Erstellung des stammdatendialoges „Projektthemen“ ist abgeschlossen

Laut Beispielbeschreibung soll der Stammdatendialog „Projektthemen“ unter dem Menüpunkt „Projektsteuerungsauskunft“ aufrufbar sein.

Wechsel Sie im AppDesigner auf „Oberfläche/ Regiezentrum“ und erstellen Sie den neuen Eintrag „mnuProjektthemen“. Hinterlegen Sie folgende Eigenschaften:

Deaktivieren Sie die Lizenzoption „im Regiezentrum verfügbar?“ des Daten-Edit-Elementes „ediProjektthemen“.

Frage: Gibt es komplexe Stammdatendialoge (z.B. mit 1:N-Beziehungen), die sich nicht als schreibende Liste abbilden lassen?

• Die Antwort ist Ja: Sie benötigen ein Daten-Edit-Element mit „Editiermodus“ = „Nicht editierbar“.
• Die Antwort ist Nein: die Erstellung von Stammdatendialogen ist abgeschlossen.

Die benötigten Metadatenobjekte bleiben natürlich auch für den „Editiermodus“ = „Nicht editierbar“ gleich. Wir benötigen also:

• Datenquelle
• Listen-Element
• Kontextmenü
• Datensatz
• Daten-Edit-Element

Die Erstellung der Metadaten erfolgt analog der Stammdaten „Projekttermine“. Nur müssen wir jetzt die Felder in Register und Feldgruppen im Detailbereich des Daten-Edit-Elementes plazieren.

Beispiel Projektsteuerung

Legen Sie die Datenquelle „dtsProjektsteuerung“ an. Basis ist die Tabelle „BPKProjektsteuerung“. Da zusätzliche Felder aus KHKProjekte und KHKKontokorrent optional angezeigt werden sollen, müssen wir in der Eigenschaft „SQL-Tabellen“ eine entsprechende SQL-Syntax hinterlegen. Die Datenquellenfelder, Titel und SQL-Abfrage sehen dann wie folgt aus:

Die Sortierung erfolgt nach dem Feld „Matchcode“. Da in der Navigationsliste der Auftraggeber vorhanden ist, und es zu einem Auftraggeber mehrere Projekte geben kann, müssen wir dafür sorgen, dass bei einer Sortierung der Liste nach „Auftraggeber“ jedesmal die Datensätze in der gleichen Reihenfolge angezeigt werden. Dies gilt natürlich auch für andere Felder. Daher tragen wir in den Eigenschaften „Ergänzende Sortierung“ und „Ergänzende Sortierung absteigend“ das Feld „SteuerungId“ (aufsteigend) ein. Wir müssen nun noch den Primäschlüssel der Tabelle für die Auswahl in der Navigationsleiste und Anzeige im Daten-Edit-Element angegeben. Falls ein Assistent es nicht bereits getan hat, tragen Sie in der Eigenschaft „Schlüsselfeld 1“ das Feld „SteuerungId“ ein.

Erstellen Sie das Listen-Element „lstProjektsteuerung“ und weisen Sie die gerade angelegte Datenquelle zu. Das Feld „SteuerungId“ wird mit „Sichtbarkeit“ = „Versteckt“ und die Felder „Telefon“, „EMail“, „Mobilfunk“, „Projektmatchcode“ und „Auftraggebermatchcode“ mit „Sichtbarkeit“ = „Ausgeblendet“. Lizenzierung „für Wawi?“ aktivieren.

Legen Sie das Kontextmenü „Projektsteuerung“ an. Legen Sie die beiden Kontextmenüeinträge „Neu“ und „Löschen“ analog dem Kontextmenü „Projektthemen“ an (oder kopieren Sie dieses Kontextmenü und benennen es um).

Legen Sie den Datensatz „recProjektsteuerung“ auf Basis der Tabelle „BPKProjektsteuerung“ an (Assistent „Tabelle importieren“). Der Primärschlüsseltyp kann von dem Assistenten nicht erkannt werden. Wir müssen die Eigenschaft „Primärschlüsseltyp 1“ auf „TAN basierend auf Tabelle 1“ ändern. Wie bei der Datenquellen tragen wir bei der „Sortierung“ die Felder „Matchcode“ und „SteuerungId“ ein.

Legen Sie das Daten-Edit-Element „ediProjektsteuerung“ (ohne Assitenten) an. Hinterlegen Sie in der Eigenschaft „Verwendungszweck“ die Option „Stammdatendialog für einen Datensatz“. Hinterlegen Sie in der Eigenschaft „Primärschlüssel 1 für Datensatz“ den Wert „1“ (Schlüsselfeld 1 der Datenquelle des Navigationselementes). Ordnen Sie den Datensatz, das Kontextmenü und das Navigationselement zu.

Legen Sie das Daten-Edit-Element „ediProjektsteuerung“ (ohne Assitenten) an. Ordnen Sie den Datensatz, das Kontextmenü und das Navigationselement zu. Hinterlegen Sie in der Eigenschaft „Verwendungszweck“ die Option „Stammdatendialog für einen Datensatz“. Legen Sie ein Daten-Element-Register „Projektsteuerung“ und folgende Daten-Element-Feldgruppen an (entsprechend den Vorgaben des Beispiels):

Über die Option „Felder importieren“ hinterlegen Sie die Felder in der im Beispiel angegebenen Feldgruppe. Das Feld „SteuerungId“ importieren Sie in die Gruppe „Projektsteuerung“ und setzen die „Sichtbarkeit“ auf „Versteckt“. Bei allen Feldgruppen aktivieren Sie die Eigenschaft „Feldgruppen-Rahmen?“.

Aktivieren Sie die Lizenzierung des Daten-Edit-Elementes „im Regiezentrum verfügbar?“.

Wenn Sie den Stammdatendialog aus dem Regiezentrum (Stammdaten/ Weitere Stammdaten/ Projektsteuerung/ Projektsteuerung) aufrufen, sollte er wie folgt aussehen:

Frage: Gibt es eine (oder mehrere) 1:N-Beziehung(en) zu einem Stammdatensatz?

• Die Antwort ist Ja: Sie benötigen einen Datensatz (oder mehrere), ein Multi-Daten-Edit-Element (oder mehrere) und ein Kontextmenü.
• Die Antwort ist Nein: Die Erstellung des Stammdatendialoges mit Detailbereich und den grundlegenden Funktionen Anlegen und Bearbeiten ist abgeschlossen.

In unserem Beispiel können Mitarbeiter einer Projektsteuerung zugeordnet werden. Die Daten werden in der Tabelle „BPKProjektsteuerungMitarbeiter“ gespeichert. Wir legen also auf Basis dieser Tabelle (mit dem Assistenten „Tabelle importieren“) den Datensatz „recProjektsteuerungMitarbeiter“ an. Der Primärschlüssel der Tabelle sind „SteuerungId“ und „Mitarbeiter“ und werden auch so vom Assistenten in die Eigenschaften „Primärschlüsselfeld 1“ und „Primärschlüsselfeld 2“ eingetragen. Die SteuerungId wird aber bei der Anlage des Hauptdatensatz vergeben (dort „Primärschlüsseltyp 1“ = „Tan-basierend auf Tabelle 1“). Daher ist in dem Datensatz „recProjektsteuerungMitarbeiter“ der „Primärschlüsseltyp 1“ = „fester, vom Parent übergebener Wert“. Die Mitarbeiternummer ist ein Stringfeld und kann daher variabel vergeben werden. Damit ist der „Primärschlüsseltyp 2“ = „variabel“.

Laut Beispielbeschreibung soll bei den Mitarbeiter nicht nur die Mitarbeiternummer, sondern auch der Matchcode und die Gruppe aus dem Mitarbeiterstamm angezeigt werden.

Bei einem Daten-Edit-Element mit „Verwendungszweck“ = „Stammdatendialog für einen Datensatz“ übernimmt das Lesen und Schreiben des Datensatzes das System. Alle Felder, die im Datensatz definiert sind, werden nach der hinterlegten SQL-Syntax (Eigenschaft „SQL-Abfrage Tabelle 1 (oder 2)“) gelesen. Geschrieben werden aber nur Felder, deren Eigenschaft „Schreibschutz?“ nicht aktiviert ist. Damit können wir beliebige Felder, die kein Bestandteil des zu schreibenden Datensatzes sind, zusätzlich in den Datensatz aufnehmen.

Legen Sie im Datensatz „recProjektsteuerungMitarbeiter“ zwei Felder mit folgenden Eigenschaften an:

• Matchcode
  • „SQL-Abfrage Tabelle 1“ = „(SELECT Matchcode FROM KHKMitarbeiter WHERE KHKMitarbeiter.Mandant = $[Mandant] AND BPKProjektsteuerungMitarbeiter.Mandant = $[Mandant] AND KHKMitarbeiter.Nummer = BPKProjektsteuerungMitarbeiter.Mitarbeiter)“
  • „Schreibschutz?“ aktivieren
• Gruppe
  • „SQL-Abfrage Tabelle 1“ = „(SELECT Bezeichnung FROM KHKGruppen INNER JOIN KHKMitarbeiter ON (KHKGruppen.Gruppe = KHKMitarbeiter.Gruppe AND KHKGruppen.Mandant = KHKMitarbeiter.Mandant AND KHKMitarbeiter.Nummer = BPKProjektsteuerungMitarbeiter.Mitarbeiter) WHERE Typ = 40046 AND KHKGruppen.Mandant = $[Mandant])“
  • „Schreibschutz?“ aktivieren

Die Verknüpfung erfolgt in dem Hauptdatensatz, also „recProjektsteuerung“. In der Gruppe „Beziehungen“ hinterlegen wir in der Eigenschaft „Detail-Datensätze“ den Datensatz „recProjektsteuerungMitarbeiter“ und geben dort auch die 1:N-Beziehung an.

Wir haben jetzt auf Datensatzebene die 1:N-Beziehnung angelegt. Über „Logischer Feldname“ (im Bild „Virtueller Feldname“) erfolgt die Verknüpfung in den UI-Elementen (Daten-Edit- und Multi-Daten-Edit-Element), es sollte daher ein „sprechender“ Name gewählt werden.

Damit haben wir die Verknüpfung auf Datensatzebene. Nun müssen wir die Verknüpfung auf UI-Ebene erstellen. Ein Datensatz, der in einer 1:N-Beziehung zu einem Hauptdatensatz steht, wird in einem Daten-Edit-Element über das Metadatenobjekt Multi-Daten-Edit-Element integriert.

Legen Sie in „Oberfläche/ Elemente/ Projektsteuerung“ das Multi-Daten-Edit-Element „mdeProjektsteuerungMitarbeiter“ mit dem Assistenten „Datenherkunft zuordnen“ an und weisen Sie diesem Element den Datensatz „recProjektsteuerungMitarbeiter“ zu. Ändern Sie den Titel in „Mitarbeiter“. Die Eigenschaft „Sichtbarkeit“ des Feldes „SteuerungId“ wird auf „Versteckt“ eingestellt. Damit dieses Element mit Tab verlassen werden kann, aktivieren wir die Eigenschaft "Hautpfeld?" beim Feld "Mitarbeiter".

Jetzt folgt die Verknüpfung zwischen Daten-Edit- und Multi-Daten-Edit-Element. Legen Sie in „ediProjektsteuerung“ das Daten-Element-Register und die Daten-Element-Feldgruppe „Mitarbeiter“ an. In der Feldgruppe legen Sie das Feld „Mitarbeiter“ an. Der Feldname kann nicht frei gewählt werden. Er muss mit dem logischen Namen des Detail-Datensatzes übereinstimmen. Der „Typ“ des Feldes ist „Unterlement“ und in der Eigenschaft „Unterelement“ hinterlegen Sie das gerade angelegte Multi-Daten-Edit-Element.

Nachdem Sie den Typ umgestellt haben, wird in den Feldern „Unterelement“ und „Zeilenanzahl“ ein Fehler ausgewiesen. Durch die Zuweisung des Unterlementes ist bei dieser Eigenschaft der Fehler behoben. Ein Multi-Daten-Edit-Element braucht eine bestimmte Anzahl an Zeilen, um komplett gerendert zu werden. Diese Zeilen werden benötigt:

• Feldgruppe-Rahmen (wird nicht angezeigt, wenn keine weitere Feldgruppe vorhanden ist)
• Hamburger-Menü und Schaltflächen
• Titelzeile
• Datensatzzeile

Daher ist der minimale Wert „4“, den wir auch in diese Eigenschaft eintragen.

Damit ist die Verknüpfung hergestellt und Ihr Stammdatendialog/ Register Mitarbeiter sollte jetzt so aussehen:

Wenn Sie in einem bestehenden Datensatz in das Register „Mitarbeiter“ wechseln, werden Sie feststellen, dass Sie einen neuen Datensatz anlegen können. Es wird also kein Kontextmenüeintrag „Neu“ benötigt. Für das Löschen eines Datensatzes einer 1:N-Beziehung müssen wir allerdings wieder ein Kontextmenüeintrag erstellen.

Legen Sie das Kontextmenü „ProjektsteuerungMitarbeiter“ an. Legen Sie den Kontextmenüeintrag „Löschen“ analog dem Kontextmenü „Projektthemen“ an (zusätzlich: "Tastenkürzel" = "Entfernen") und weisen Sie dieses Kontextmenü dem Multi-Daten-Edit-Element zu.

Damit haben wir einen Stammdatendialog mit einer 1.N-Beziehung und den grundlegenden Funktionen wie Anlegen, Bearbeiten und Speichern erstellt.

Frage: Gibt es so viele Daten in einer 1:N-Beziehung, dass eine Bearbeitung in der Liste nicht zuzumuten wäre?

• Antwort ist Ja: Sie benötigen ein zusätzliches Daten-Edit-Element und ein Kontextmenüeintrag.
• Antwort ist Nein: Die Implementierung der 1:N-Beziehung (Anzeige, Anlegen, Bearbeiten und Speichern) ist abgeschlossen.

Die Implementierung eines "Bearbeiten"-Dialoges für eine 1:N-Beziehung erfolgt nach diesem Muster:

• Kontextmenüeintrag im Kontextmenü des Multi-Daten-Edit-Elementes mit Funktionsaufruf "DatensatzBearbeiten.Sage.System"
• Zuordnung des "Bearbeiten"-Dialoges (Daten-Edit-Element) in der Eigenschaft "Child-Element" des Kontextmenüeintrages

Wir müssen also zuerst das Daten-Edit-Element anlegen. Legen Sie in der Gruppe "Projektsteuerung" das Daten-Edit-Element "ediProjektsteuerungMitarbeiter" an. Ändern Sie die folgenden Eigenschaften:

• "Titel" = "Mitarbeiter"
• "Verwendungszweck" = "Stammdatendialog für einen Datensatz"
• "Dialoggruppe" = "Stammdaten"
• "Datensatz" = "recProjektsteuerungMitarbeiter.<partnerid>.<loesungid>"

Legen Sie das Daten-Element-Register "Mitarbeiter" mit folgenden Daten-Element-Feldgruppen und Feldern (Felder importieren) an:

• Feldgruppe "Mitarbeiter"
  • "Feldgruppen-Rahmen?"  aktivieren
  • Feld "Mitarbeiter"
  • Feld "Matchcode"
  • Feld "Gruppe"
  • Feld "SteuerungId" mit "Sichtbarkeit" = "Versteckt"
• Feldgruppe "Fahrzeug"
  • "Feldgruppen-Rahmen?"  aktivieren
  • Feld "Firmenwagen"
  • Feld "Navigation"
  • Feld "Mitnahme"
• Feldgruppe "Sontiges"
  • "Feldgruppen-Rahmen?"  aktivieren
  • Feld "Notebook"
  • Feld "StellvertreterProjektleitung"
  • Feld "ZugriffProjekt"

Das Kontextmenü des Multi-Daten-Edit-Elementes haben wir bereits angelegt ("ProjektsteuerungMitarbeiter"). Legen Sie in diesem Kontextmenü den Kontextmenüeintrag "Bearbeiten" an und ändern Sie folgende Eigenschaften:

• "Funktionstitel" = "Bearbeiten"
• "Funktionskurztitel" = "Bearbeiten"
• "Position in Sortierung" = "2"
• "Schaltflächenposition" = "2"
• "Festlegung Aktivierung durch Feld" = "[_DialogState]="Edit""
• "Funktionsaufruf" = "DatensatzBearbeiten.Sage.System"
• "Child-Element" = "ediProjektsteuerungMitarbeiter.<partnerid>.<loesungid>"
• "für Wawi?" aktivieren

Wenn Sie in der Warenwirtschaft den Stammdatendialog "Projektsteuerung" aufrufen, einen Datensatz markieren und im Register "Mitarbeiter" den Kontextmenüeintrag "Bearbeiten" ausführen, sollte der Dialog so aussehen (das die Mitarbeiternummer editiert werden kann, wird später noch behandelt):

Frage: Gibt es eine oder mehrere N:M Beziehung?

• Antwort ist Ja: Sie benötigen einen Datensatz (oder mehrere), ein Multi-Daten-Edit-Element (oder mehrere) und ein Kontextmenü.
• Antwort ist Nein: Die Implementierung der 1:N-Beziehung (Anzeige, Anlegen, Bearbeiten und Speichern) ist abgeschlossen.

In unserem Beispiel soll zu jedem Mitarbeiter die Zeiten erfasst werden, die für bestimmte Aktionen in einem Projekt geplant sind. Die geplanten Zeiten sind also eine N:M-Beziehung.

Wir benötigen einen Datensatz. Legen Sie den Datensatz "recProjektsteuerungMitarbeiterPlanung" an (Tabelle importieren, Tabelle = "BPKProjektsteuerungMitarbeiterPlanung"). Für die Beziehung müssen folgende Änderungen am Datensatz vorgenommen werden:

• "Primärschlüsselfeld 2" = "SteuerungId"
• "Primärschlüsselfeld 3" = "Mitarbeiter"
• "Primärschlüsseltyp 1" = "TAN-basierend auf Tabelle 1"
• "Primärschlüsseltyp 2" = "fester, vom Parent übergebener Wert"
• "Primärschlüsseltyp 3" = "fester, vom Parent übergebener Wert"

Führen Sie an folgenden Feldern Änderungen durch:

• Feld "DatumBis"
  • "Feldtitel" = "Bis"
  • "Datentyp" = "Date"
• Feld "DatumVon"
  • "Feldtitel" = "Von"
  • "Datentyp" = "Date"

Selektieren Sie den Datensatz "recProjektsteuerungMitarbeiter" und hinterlegen Sie in der Eigenschaft "Detail-Datensätze" den neuen Datensatz mit "Virtueller Feldname" = "Mitarbeiterplanung" und der Datensatzbeziehung "Schlüssel Master-Datensatz" = "SteuerungId" und "Mitarbeiter" und "Schlüssel Detail-Datensatz" = "SteuerungId" und "Mitarbeiter".

• Anlage des Kontextmenüs "ProjektsteuerungMitarbeiterPlanung"
  • Anlage des Kontextmenüeintrags "Loeschen"
    • "Funktionstitel" = "Löschen"
    • "Funktionskurztitel" = "Löschen"
    • "Tastenkürzel" = "Entfernen"
    • "Position in Sortierung" = "1"
    • "Schaltflächenposition" = "1"
    • "Festlegung Aktivierung durch Feld" = "[_DialogState]="Edit""
    • "Funktionsaufruf" = "DatensatzLoeschen.Sage.System"
    • "für Wawi?" aktivieren
• Anlage des Multi-Daten-Edit-Elementes "mdeProjektsteuerungMitarbeiterPlanung"
  • "Datensatz" = "recProjektsteuerungMitarbeiterPlanung.<partnerid>.<loesungid>"
  • "Kontextmenü" = "ProjektsteuerungMitarbeiterPlanung.<partnerid>.<loesungid>"
  • Anlage der Multi-Daten-Edit-Element-Vorlage "Standard"
    • Import aller Felder
    • "Sichtbarkeit" = "Versteckt" bei den Feldern "SteuerungId, ""Mitarbeiter" und "PlanungId"

Bei der Beschreibung der weiteren Änderungen oder Neuanlage von Metadaten wird vorausgesetzt, dass Sie das Daten-Edit-Element "ediProjektsteuerungMitarbeiter" angelegt haben (das ist der "Bearbeiten"-Dialog der vorherigen Frage).

• Anlegen der Daten-Element-Feldgruppe "Planung" im Register "Mitarbeiter" des Daten-Edit-Elementes "ediProjektsteuerungMitarbeiter"
  • "Neue Zeile beginnen" aktivieren
  • "Feldgruppen-Rahmen" aktivieren
  • Anlage des Feldes "Mitarbeiterplanung" (= virtueller Name in "Detail-Datensätze" in recProjektsteuerungMitarbeiter)
    • "Typ" = "Unterelement"
    • "Unterelement" = "mdeProjektsteuerungMitarbeiterPlanung.<partnerid>.<loesungid>"
    • "Zeilenanzahl" = "4"

Damit haben wir einen funktionsfähigen Stammdatendialog mit einer 1:N:M-Beziehung angelegt. Im Client sieht diese Beziehung so aus:

Soll für die M-Beziehung ein "Bearbeiten"-Dialog zur Verfügung stehen, dann ist wie bei dem "Bearbeiten"-Dialog der N-Beziehung vorzugehen.

Frage: Basieren Daten, die in der Liste und/oder des Daten-Edit-Elementes angezeigt werden, auf Daten, die in der Mandanten-Datenbank mit Werten gespeichert werden, die nicht der gewünschten Anzeige entsprechen (in unserem Beispiel "Status“, "Projekttyp“, "Planung" und alle boolschen Felder)?

• Antwort ist Ja: Sie benötigen zusätzlich String Ressourcen.
• Antwort ist Nein: Daten werden weiterhin als Integerwerte bzw. Checkboxen angezeigt

Legen Sie die String Ressourcen anhand der Tabellenbeschreibung des Beispiels:

Für boolsche Felder stellt das System die Ressourcen (String Ressourcen „Ja“ und „Nein“) bereit.

Der „Datentyp“ der Felder "Status", "Projekttyp", "Planung" und aller boolschen Felder (Datensatz „recProjektsteuerung“, „recProjektsteuerungMitarbeiter“ und „recProjektsteuerungMitarbeiterPlanung“) wird auf „Indizierter String“ geändert und die String Ressourcen in der Eigenschaft „Datentyp Ergänzung“ zugeordnet. Für das Feld "Planung" verwenden wir die Ressourcen der Themengruppe, die bereits für die Themenverwaltung angelegt wurden.

Frage: Müssen Daten erfasst und/oder angezeigt werden, die zwar in den zugrundeliegenden Tabellen des Stammdatendialogs gespeichert, aber auf Daten beruhen, die in anderen Bereichen der Applikation erfasst werden?

• Antwort ist Ja: Sie benötigen zusätzliche Datenreferenzen und/oder Datenklassen und/oder serverseitige Datenbeschaffung
• Antwort ist Nein: Weiter mit der Bearbeitung des Stammdatendialoges

Die Auswahl des Projektleiters soll sich auf angelegte Benutzer der Applikation beziehen. Die Auswahl erfolgt daher aus einer Datenreferenz. Im Standard wird diese Auswahl bereits in mehreren Bereichen verwendet. Wir hinterlegen im Feld „Projektleiter“ des Datensatzes „recProjektsteuerung“ die „Datenreferenz“ = „dtrBenutzer.Sage.System“.

Im Feld „Kontakt“ soll aus den Ansprechpartner des Projekt-Auftraggebers oder eine freie Eingabe möglich sein. Das Feld darf nicht leer sein. Das eine Eingabe erforderlich ist, haben wir bereits durch die Tabellendefinition (NOT NULL) festgelegt. Durch diese Definition ist das Feld „Kontakt“ bei der Erstellung des Datensatzes bereits mit der Aktivierung von „Pflichtfeld?“ in den Metadaten angelegt worden. Für diese Varianten müssen wir eine entsprechende Datenreferenz anlegen.

Bei der Zuordnung einer Datenreferenz zu einem Datensatzfeld gibt es zusätzliche Eigenschaften.

Sollen alle Daten, die als Ergebnis der SQL-Abfrage der Datenreferenz geliefert werden, als Auswahl zur Verfügung stehen, dann reicht die Zuordnung der Datenreferenz. Soll nur eine Teilmenge des Ergebnisses zur Auswahl zur Vefügung stehen und ändert sich die erwartete Teilmenge in Abhängigkeit von Daten des Datensatzes, dann gilt: die SQL-Abfrage der Datenreferenz muss alle möglichen Daten liefern. Die Definition der Teilmenge erfolgt über die Eigenschaft „Datenreferenz-Filter“. Technisch wird nichts anderes gemacht, als diese Einschränkung an die WHERE-Bedingung der Datenreferenz anzuhängen. Kann die Einschränkung nicht über eine WHERE-Bedingung erfolgen, dann kann man eine dynamische Datenreferenz (alle Eigenschaften mit „(dynamisch)“) erstellen. Auch hier gilt: die SQL-Abfrage liefert alle Daten. Im Code teilt man dem System mit, welche „Schlüssel“ (Schlüsselfeld der Datenreferenz) angezeigt werden sollen. Ab der Version 8.1 gibt es eine weitere Variante, die die Ermittlung der Daten in einen Geschäftsprozess mit Übergabe von Parametern durchführt. Für unser Beispiel brauchen wir diesen Fall nicht. Die Verwendung bzw. die Codierung und die zu verwendende Basisklasse werden an anderer Stelle erläutert. Die Definition der Datenreferenzen und auch die Varianten der Filterung/ Erstellung sind hier Datenreferenzen beschrieben.

In der Regel besteht die Abfrage der Datenreferenz aus zwei Feldern: Schlüssel und Bezeichnung. Wobei der Schlüssel wiederum in der Applikation sichtbar oder nicht sichtbar sein kann. Ist der Schlüssel sichtbar und man möchte ihn auch in dem Feld im Daten-Edit-Element anzeigen (anlog den Datenklassen), dann muss man ein zusätzliches verstecktes, schreib geschütztes Feld anlegen. Über die Eigenschaft „Datenreferenz-Info-Felder“ kann man dann die Zuordnung der Daten aus der Datenreferenz hinterlegen. Dabei wählt man die Reihenfolge Felder des Datensatzes entsprechend der „Priorität“ der Datenreferenzfelder. Wir wollen nur den Ansprechpartner auswählbar machen, brauchen also nur ein Feld. Der Filter der Datenreferenz ist die Adresse des Auftragsgebers.

Legen Sie unter „Daten/ Datenreferenzen/ Projektsteuerung“ die Datenreferenz „dtrAnsprechpartnerProjektsteuerung“ an. Legen Sie die Datenreferenzfelder Adresse mit „Priorität“ = „0“, „Datentyp“ = „Integer“ und Ansprechpartner mit „Priorität“ = „1“ an. Die Eigenschaften der Datenreferenz legen Sie wie folgt an:

• „Titel“ = „Ansprechpartner“
• „Schlüsselfeld“ = „Ansprechpartner“
• „Freie Eingabe erlaubt?“ aktivieren (damit kann auch in einem Pflichtfeld eine freie Eingabe erfolgen)
• „SQL-Tabellen“ = „KHKAnsprechpartner“
• „SQL-Where-Bedingung“ = „Mandant = $[Mandant]“
• „Sortieren nach Feld“ = „Ansprechpartner“

Damit wir auf die Adresse filtern könnne, muss das Feld im Datensatz vorhanden sein. Wir legen das Feld „Adresse“ mit folgenden Eigenschaften in „recProjektsteuerung“ an. „SQL-Abfrage-Tabelle 1“ = „(SELECT Adresse FROM KHKKontokorrent INNER JOIN KHKProjekte ON (KHKKontokorrent.Mandant = KHKProjekte.Mandant AND KHKKontokorrent.Kto = KHKProjekte.Auftraggeber) WHERE KHKKontokorrent.Mandant = @Mandant AND BPKProjektsteuerung.Mandant = @Mandant AND KHKKontokorrent.KtoArt = 'D' AND BPKProjektsteuerung.Projekt = KHKProjekte.Projektnummer)“

• „Datentyp“ = „Integer“
• „Schreibschutz“ aktivieren

Dem Feld „Kontakt“ in „recProjektsteuerung“ weisen wir die neue Datenreferenz zu und hinterlegen in der Eigenschaft „Datenreferenz-Filter“ = „Adresse = [Adresse]“.

Die Projekte und Mitarbeiter sind Stammdaten der Applikation. Suche und Auswahl von Stammdaten innerhalb der Applikation erfolgt über die Definition einer OL-Klasse in den Applikationsdatenbanken. In der auf Metadatenobjekte basierenden Oberfläche erfolgt die Suche und Auswahl über Datenklassen (Daten/ Datenklassen).

Für Projekte („clsProjekte.Sage.System“) und Mitarbeiter („clsMitarbeiter.Sage.System“) sind die Datenklassen im Standard vorhanden.

In der alten Technik werden Key und Matchcode getrennt dargestellt. In den auf Metadaten basierenden UI erfolgt die Anzeige nach dem Muster „Key | Matchcode“ in einem Feld. Trotzdem muss ein Feld des Datensatzes den Matchcode der Datenklasse aufnehmen. Das wird wird allerdings mit „Schreibschutz?“ und „Sichtbarkeit“ = „Versteckt“ angelegt.

Wir ändern und erweitern die Metadaten wie folgt:

• Feld „Projekt“ in „recProjektsteuerung“
  • „Datentyp“ = „Schlüssel 1 einer Datenklasse“
  • „Datenklasse“ = „clsProjekt.Sage.System“
• Neues Feld „Projektmatchcode“ in „recProjektsteuerung“
  • „SQL-Abfrage Tabelle 1“ = „(SELECT Matchcode FROM KHKProjekte WHERE KHKProjekte.Mandant = $[Mandant] AND KHKProjekte.Mandant = BPKProjektsteuerung.Mandant AND KHKProjekte.Projektnummer = BPKProjektsteuerung.Projekt)“
  • „Datentyp“ = „Matchcode für Schlüssel 1 einer Datenklasse“
  • „Datenklasse“ = „clsProjekt.Sage.System“
  • „Datenklassen-Schlüsselfeld“ = „Projekt“ (Dieser Eintrag bezieht sich auf ein Feld im aktuellen Datensatz mit „Datentyp“ = „Schlüssel 1-3 einer Datenklasse“. Es ist nicht das Feld der Datenklasse selber.)
  • „Schreibschutz?“ aktivieren
• Feld „Projektmatchcode“ in „ediProjektsteuerung – Projektsteuerung - Projektsteuerung“ importieren
  • „Sichtbarkeit“ = „Versteckt“

Wir zeigen viele Daten an, die abhängig vom Projekt sind. Wird bei einem neuen Datensatz das Projekt gewechselt, dann wird zwar der Matchcode des Projektes via Datenklassen vom System geliefert, Adresse, Auftraggeber und alle Kontaktdaten basieren aber noch auf das vorherige Projekt. Wir müssen also auf die Änderung des Projektes im Ereignis "Nach Aktualisierung" reagieren. Da wir Daten nachlesen müssen, kann die Aktualisierung nur mit Makro "AufrufenDll" erfolgen.

Codieren Sie die Aktualisierungen und hinterlegen Sie im Ereignis „Nach Aktualisierung“ den Makrobefehl "AufrufenDll".

Die gleichen Änderungen sind für die Auswahl der Mitarbeiter auszuführen. Hier haben wir allerdings das Matchcodefeld bereits und die Darstellung in einem Multi-Daten-Edit-Element ist anders. Der Matchcode muss in einem seperaten Feld angezeigt werden. Folgende Änderungen in den Metadaten sind durchzuführen:

• Feld „Mitarbeiter“ in „recProjektsteuerungMitarbeiter“
  • „Datentyp“ = „Schlüssel 1 einer Datenklasse“
  • „Datenklasse“ = „clsMitarbeiter.Sage.System“
• Feld „Matchcode“ in „recProjektsteuerungMitarbeiter“
  • „Datentyp“ = „Matchcode für Schlüssel 1 einer Datenklasse“
  • „Datenklasse“ = „clsMitarbeiter.Sage.System“
  • „Datenklassen-Schlüsselfeld“ = „Mitarbeiter“

Wenn Sie sich jetzt das Register „Mitarbeiter“ im Stammdatendialog „Projektsteuerung“ anschauen, dann werden Sie feststellen, dass keine Suchfunktion im Mitarbeiterfeld vorhanden ist. Das liegt an unserer Definition des Schlüssels in „recProjektsteuerungMitarbeiter“. Hier hatten wir für das Feld „Mitarbeiter“ die Eigenschaft „Primärschlüsseltyp 2“ auf „variabel“ gesetzt. Die Eingabe ist aber nun nicht mehr variabel, sondern die Daten kommen aus einen anderen Bereich der Stammdaten, sind in diesen Datensatz also ein „Fremdschlüssel“. Ändern Sie die Eigenschaft „Primärschlüsseltyp 2“ auf „Fremdschlüssel“.

Bleibt noch das Feld "Gruppe", welches nicht zum Datensatz gehört, bei einer Neuanlage aber gefüllt werden muss. Hier kommen wir nicht drumherum ein Request zum Server zu machen. Nach Aktualisierung des Feldes "Mitarbeiter" müssen wir die Bezeichnung der Gruppe des Mitarbeiters aus KHKGruppen lesen. Da es kein Feld des Datensatzes ist und nur für die Anzeige auf dem Client verwendet wird, hinterlegen wir das Makro im Feld des Multi-Daten-Edit-Elementes und nicht im Feld des Datensatzes.

Selektieren Sie das Multi-Daten-Edit-Element "mdeProjektsteuerungMitarbeiter" und wählen Sie aus der Vorlage "Standard" das Feld "Mitarbeiter" aus.

Hinterlegen Sie im Ereignis „Nach Aktualisierung“ den Makrobefehl "AufrufenDll".

Frage: Soll bei der Bearbeitung von Daten automatiserte Abläufe/ Vereinfachungen erfolgen?

• Antwort ist Ja: Sie benötigen Makros und/oder eine serverseitige .Net-DLL.
• Antwort ist Nein: Weiter mit der Bearbeitung des Stammdatendialoges

Laut Beispielbeschreibung soll bei einer Änderung des Ansprechpartners auf Rückfrage Daten aus den Ansprechpartnerdaten übernommen und bei Änderung des „Status“ auf „Abgeschlossen“, ebenfalls nach Rückfrage, „Aktiv“ auf „Nein“ gesetzt werden.

Für die erste Anforderung müssen wir Daten Lesen. Es kann also nur das Makro „AufrufenDll“ verwendet werden. Da eine freie Eingabe möglich ist, kann es also sein, dass keine Daten übernommen werden können und damit auch die Abfrage nicht erscheinen darf. Da wir über die Basisklasse MacroProcessBase auch Variable erzeugen und im weiteren Verlauf des Makros auf diese Variablen zugreifen können, benötigen wir nur einen Request. Im Response geben wir dann das Ergebnis von „Ist eine Abfrage nötig“, sowie die Daten, falls vorhanden, zurück.

Wir legen in Sagede.ADID.Projektsteuerung.RealTimeData.Makros die Klasse ProjektsteuerungKontaktAfterUpdate an.

Für das Auslösen der Makrobefehle verwenden wir das Ereignis „Nach Aktualisierung“ der Daten-Edit-Element-Felder „Kontakt“ und „Status“. Um die Makrobefehle komplett hinterlegen zu können, müssen wir die Abfragen unter „Grundlagen/ Meldungen“ anlegen.

• „Name“ = „ProjektsteuerungKontakt“
  • „Titel“ = „Projektsteuerung“
  • „Meldungstext“ = „Sollen die Daten aus dem Ansprechpartnerstamm übernommen werden?“
  • „Typ“ = „Konfirmation mit drei Schaltflächen“
  • „Schaltflächen-Text 1“ = „Ja“
  • „Schaltflächen-Text 2“ = „Nein“
• „Name“ = „ProjektsteuerungAbgeschlossen“
  • „Titel“ = „Projektsteuerung“
  • „Meldungstext“ = „Soll das Kennzeichen 'Aktiv' auf 'Nein' gesetzt werden?“
  • „Typ“ = „Konfirmation mit drei Schaltflächen“
  • „Schaltflächen-Text 1“ = „Ja“
  • „Schaltflächen-Text 2“ = „Nein“

Jetzt können wir die Makrobefehle hinterlegen. Für das Feld „Kontakt“ verwenden wir folgende Makrobefehle im Ereignis „Nach Aktualisierung“.

Für das Feld „Status“ die folgenden Befehle.

Das Feld "Mitarbeiter" im Register "Mitarbeiter" kann editiert werden. Da ein Schlüssel nicht nachträglich geändert werden kann, wäre es unsinnig das Feld editierbar zu lassen, um dann beim Speichern diese Änderung zu verweigern. Das Feld soll bei alten und neuen Datensätzen nicht editierbar sein. Da das Ereignis "Beim Setzen" beim Laden und nach dem Ereignis "Nach Aktualisierung" ausgeführt wird und dazu das Ereignis ist, um die Stati (z.B. editierbar/nicht editierbar, sichtbar/nicht sichtbar) von Feldern zu setzen (Ereignisse), hinterlegen wir in diesen Ereignis im Feld "Mitarbeiter" des Multi-Daten-Edit-Elementes "mdeProjektsteuerungMitarbeiter" die entsprechenden Makrobefehle.

Gibt man Daten in einem Multi-Daten-Edit-Element ein, will man irgendwann die Bearbeitung verlassen. Wenn die Eingabe über Tastatur erfolgen kann, dann möchte man vermutlich auch über Tastatur die Liste verlassen. Dafür gibt es in einem Feld eines Multi-Daten-Edit-Elementes die Eigenschaft "Hauptfeld?". Wählen Sie das Feld "Mitarbeiter" aus "mdeProjektsteuerungMitarbeiter" und aktivieren Sie die Eigenschaft "Hauptfeld?". Führen Sie das Gleich beim Feld "DatumVon" in "mdeProjektsteuerungMitarbeiterPlanung" aus.

Frage: Sollen für einen gewählten Datensatz zusätzliche Aktionen zur Verfügung stehen?

• Antwort ist Ja: Sie benötigen zusätzliche Kontextmenüeinträge
• Antwort ist Nein: Weiter mit der Bearbeitung des Stammdatendialoges

Laut Beispiel soll man aus dem Stammdatendialog in den Kunden-, Projekt- und Themenstamm verzweigen könnnen.

In Funktionsaufrufe in Kontextmenüs sind die dazu benötigten Funktionsaufrufe erklärt, bzw. den Aufruf von Kunden- und Projektstamm wurde bereits für die Projektsteuerungsauskunft implementiert. Wir verwenden in einem Datensatz allerdings nicht die Schlüsselfelder der Datenquelle, sondern die Felder des Datensatzes. Damit ändern sich auch die Platzhalter, genauer muss man sagen, die Platzhalter werden erweitert. Der Platzhalter $[KeyField()] funktioniert für VBA-Aufrufe nach wie vor, das Feld muss dann in der Datenquelle des Navigationselementes als Schlüsselfeld eingetragen sein. Über den Platzhalter $[FieldValue(feldname)] kann auf jedes Feld eines Datensatzes zugegriffen werden.

Selektieren Sie das Kontextmenü "Projektsteuerung" und legen Sie folgende Kontextmenüeinträge an.

• Anlage des Kontextmenüeintrags "Kundenstamm"
  • "Funktionstitel" = "Kundenstamm"
  • "Funktionskurztitel" = "Kundenstamm"
  • "Position in Sortierung" = "3"
  • "Schaltflächenposition" = "3"
  • "Festlegung Aktivierung durch Feld" = "[_DialogState]="Edit""
  • "Tooltipp im deaktivierten Zustand" = "Dieser Eintrag steht bei neuen Datensätzen nicht zur Verfügung."
  • "Funktionsaufruf“ = "MakroStarten.Sage.System“
  • "Ausführen Makro" = Befehl: DatenEditDialogÖffnen, Parameter 1: ediKundenstamm.Sage.System, Parameter 2: [Adresse];[Auftraggeber]
  • "für Wawi?" aktivieren
• Anlage des Kontextmenüeintrags "Projektstamm"
  • "Funktionstitel" = "Projektstamm"
  • "Funktionskurztitel" = "Projektstamm"
  • "Position in Sortierung" = "4"
  • "Schaltflächenposition" = "4"
  • "Festlegung Aktivierung durch Feld" = "[_DialogState]="Edit""
  • "Tooltipp im deaktivierten Zustand" = "Dieser Eintrag steht bei neuen Datensätzen nicht zur Verfügung."
  • "Funktionsaufruf" = "gbFrmOpenLookup.Sage.System"
  • "Parameter 1 Funktionsaufruf" = ""frmAbfDataProjekte""
  • "Parameter 2 Funktionsaufruf" = "$[FieldValue(Projekt)]"
  • "Parameter 3 Funktionsaufruf" = "0"
  • "für Wawi?" aktivieren
• Anlage des Kontextmenüeintrags "Projektthemen"
  • "Funktionstitel" = "Projektthemen"
  • "Funktionskurztitel" = "Projektthemen"
  • "Position in Sortierung" = "5"
  • "Schaltflächenposition" = "5"
  • "Festlegung Aktivierung durch Feld" = "[_DialogState]="Edit""
  • "Tooltipp im deaktivierten Zustand" = "Dieser Eintrag steht bei neuen Datensätzen nicht zur Verfügung."
  • "Funktionsaufruf“ = "MakroStarten.Sage.System“
  • "Ausführen Makro" = Befehl: DatenEditDialogÖffnen, Parameter 1: ediKundenstamm.Sage.System, Parameter 2: [Adresse];[Auftraggeber]
  • "für Wawi?" aktivieren

Frage: Sollen Standardfunktionalitäten in der Applikation zur Verfügung stehen?

• Die Antwort ist Ja: Sie benötigen Metadaten/Datenbankanpassungen für Datenklasse, benutzerdefinierte Felder, Historie, Wiedervorlage, Sammelmappe
• Die Antwort ist Nein: Wenn Sie einen Datensatz kopieren wollen, dann brauchen Sie die Datenklasse, ansonsten weiter mit Validierungen

Datenklasse

Die Datenklassen der Sage 100 dienen in erster Linie dazu Suchen bzw. Eingaben in Feldern durch eine Vorschlagsliste zu vereinfachen. In einigen Bereichen, die aktuell nichts mit Metadaten (also der neuen Technik) zu tun haben, werden Sie verwendet, um standardisiert auf Daten zugreifen zu können (z.B. die Daten aus USysClassHistory, auf der die Control-Center-Elemente "Meine letzten ..." basieren oder die benutzerdefinierten Felder).

Der erste Schritt ist, den Namen der Klasse festzulegen. Wir benennen unsere Klasse "BPKProjektsteuerung". Wir werden die Datenklassen auch in beiden Bereichen anlegen müssen,

Zum einen in den Metadaten, damit in den UI-Elementen, die auf Metadaten basieren nach den einzelnen Projektsteuerungen gesucht werden kann. Diese Funktionalität benötigen wir jetzt nicht sofort (es sei denn wir wollen Datensätze via System kopieren), wollen sie aber hier jetzt anlegen.

Datenklassen auf Basis von Metadaten (Daten/ Datenklassen) beziehen sich auf eine oder mehrere Tabellen und haben ein oder mehrere Schlüsselfelder. Daher sind nur die Eigenschaften "SQL-Tabellen" und "SQL-Feldname Schlüssel 1" Pflichtfelder. Für die Suche kann ein Daten-Such-Element zugeordnet werden. Das Daten-Such-Element wiederum besteht aus den Metadatenobjekten Datenquelle und Listen-Element. Sollen bestimmte Aktionen mit der Datenklassen verbunden werden, dann kann auch ein Kontextmenü zugeordnet werden.

Erstellen wir die Datenquelle und Listen-Element für das Datensuch-Element. Ausreichende Suchmöglichkeiten sollten wir bereits im Navigationselement zur Verfügung gestellt haben. Daher Kopieren wir die Datenquelle "dtsProjektsteuerung" und benennen die Kopie um in "dtsProjektsteuerungsuche" und den Titel in "Projektsteuerungssuche". Dann legen wir das Listen-Element "lstProjektsteuerungsuche" mit den Assistenten "Datenquelle zuordnen" an und ändern den Titel in "Projektsteuerungssuche" und setzen die "Sichtbarkeit" des Feldes "SteuerungId" auf "Versteckt" und aktivieren Sie "für Wawi?". Es folgt das Daten-Such-Element und die Datenklasse.

• Anlage des Daten-Such-Elementes "seaProjektsteuerungsuche"
  • "Titel" = "Projektsteuerungssuche"
  • "Master-Element" = "lstProjektsteuerungsuche.<ihre_partnerid>.<ihre_loesungid>"
  • "Schlüsselfeld" = "SteuerungId"
  • "Matchcode" = "Matchcode"
• Anlage der Datenklasse "clsProjektsteuerung"
  • "Titel" = "Projektsteuerung"
  • "Datentyp Schlüssel 1" = "TAN"
  • "Schlüssel sichtbar?" deaktivieren
  • "Daten-Such-Element" = "seaProjektsteuerungsuche.<ihre_partnerid>.<ihre_loesungid>"
  • "SQL-Tabellen" = "BPKProjektsteuerung"
  • "SQL-Where-Bedingung" = "BPKProjektsteuerung.Mandant = $[Mandant]"
  • "SQL-Feldname Schlüssel 1" = "BPKProjektsteuerung.SteuerungId"
  • "SQL-Feldname Matchcode 1" = "BPKProjektsteuerung.Matchcode"
  • "SQL-Abfrage aktiver Datensatz" = "BPKProjektsteuerung.Aktiv <> 0"

Für die Anlage der Datenklasse in der Applikationsdatenbank gibt es zwei Wege. Wird noch ein AddIn verwendet, dann trägt man die Angaben in die Steuerungstabellen des Template-AddIns ein. Braucht man kein AddIn für seine Erweiterungen/Anpassungen kann man ein Programm schreiben, welches nach dem Liveupdate und vor dem Start der Applikation ausgeführt und die Einträge in die Applikationsdatenbank vornimmt. Für die zweite Variante müsste man also ein ausführbares Programm codieren und in den Metadaten unter "Erweiterungen/ Dateien" hinterlegen, so dass dieses Programm mit den Metadaten installiert und ausgeführt wird (Erweiterungen). Bitte beachten Sie dazu den Hinweis am Ende dieses Kapitels.

Wollen Sie nur dieses Beispiel durchgehen, dann können Sie die Einträge auch manuell durchführen. Legen Sie in der Applikationsdatenbank der Warenwirtschaft in der Tabelle USysClass folgenden neuen Datensatz an:

• "Class" = "BPKProjektsteuerung"
• "Caption" = "Projektsteuerung"
• "Table" = "BPKProjektsteuerung"
• "Clause" = "BPKProjektsteuerung.Mandant=$1"
• "KeyName" = "SteuerungId"
• "KeyType" = "1"
• "Lookup" = "Matchcode"
• "SupportsActive" aktivieren

Benutzerdefinierte Felder

Um in der Applikation (genauer im Administrator) benutzerdefinierte Felder anlegen zu können, muss ein Eintrag in eine Systemtabelle erfolgen. Damit die benutzerdefinierten Felder in den neuen Stammdatendialogen zur Verfügung stehen, muss eine Datenklassen (OL-Klasse) in der Sage 100 vorhanden sein und diese in den Metadaten des betreffenden Datensatzes hinterlegt werden.

Den Eintag in die Systemtabelle führen wir im Updateskript durch.

Die OL-Klasse haben wir im vorherigen Kapitel angelegt (über AddIn, ausführbares Programm oder manuelle Eingabe).

Selektieren Sie den Datensatz "recProjektsteuerung" und tragen Sie in der Eigenschaft "OL-Klassen der benutzerdefinierten Felder" die Klasse "BPKProjektsteuerung" ein.

Historie

Damit bei Anlage oder Änderung eines Stammdatensatzes ein Eintrag in "USysClassHistorie" erfolgt, benötigen wir eine OL-Klasse und Angaben in den Metadaten.

Die OL-Klasse haben wir im vorherigen Kapitel angelegt (über AddIn, ausführbares Programm oder manuelle Eingabe).

Selektieren Sie den Datensatz "recProjektsteuerung" und tragen Sie in der Eigenschaft "Klassen-Schlüssel für Historie 1" die Klasse "BPKProjektsteuerung" und in "Feldnamen für Historie 1" das Feld "SteuerungId" ein. Damit werden Einträge in UsysClassHistory vorgenommen, die dann z.B. für eine Control-Center-Auswertung "Meine letzten Projektsteuerungen" verwendet werden können.

Wiedervorlage

Damit die Standardfunktion "Wiedervorlage" (VBA-Aufrufe) verwendet werden kann, benötigen wir eine OL-Klasse und einen Eintrag in USysClassMenu. Der Eintrag in USysClassMenu erfolgt programmatisch zusammen mit dem Eintrag in USysClass.

Wollen Sie nur dieses Beispiel durchgehen, dann können Sie die Einträge auch manuell durchführen. Legen Sie in der Applikationsdatenbank der Warenwirtschaft in der Tabelle USysClassMenu folgenden neuen Datensatz an:

• "Class" = "BPKProjektsteuerung"
• "Default" aktivieren
• "Function" = "gbOpenDataEditPart("ediProjektsteuerung.<ihre_partnerid>.<ihre_loesungid>","$1")"
• "Key" = "BPKProjektsteuerung_Wiedervorlage"

Wählen Sie das Kontextmenü "Projektsteuerung" aus.

• Anlage des Kontextmenüeintrags "Wiedervorlage"
  • "Funktionstitel" = "Wiedervorlage"
  • "Funktionskurztitel" = "Wiedervorlage"
  • "Position in Sortierung" = "6"
  • "Schaltflächenposition" = "6"
  • "Gruppe beginnen?" aktivieren
  • "Festlegung Aktivierung durch Feld" = "[_DialogState]="Edit""
  • "Tooltipp im deaktivierten Zustand" = "Dieser Eintrag steht bei neuen Datensätzen nicht zur Verfügung."
  • "Funktionsaufruf" = "gbClassSchedule.Sage.System"
  • "Parameter 1 Funktionsaufruf" = ""BPKProjektsteuerung""
  • "Parameter 2 Funktionsaufruf" = "$[KeyField(1)]"
  • "Parameter 3 Funktionsaufruf" = "0"
  • "Parameter 4 Funktionsaufruf" = ""Projektsteuerung""
  • "für Wawi?" aktivieren

Sammelmappe

Das System stellt zwei Arten von Mappen zur Verfügung.

• Notizen
• Dokumente

Die Mappen der Dokumente können in bis zu 20 Mappen unterteilt werden. Die Unterteilung in der Applikation erfolgt in den Grundlagen. Man hinterlegt pro Dokumentenmappe die Bezeichnung der Registerkarte. Um die Bezeichnungen hinterlegen zu können, benötigt man einen EIntrag in der Tabelle USysRegistry der Applikationsdatenbank. Die Anzeige der Bezeichnungen, sowie das Wegschalten nicht benutzter Register muss codiert werden (Ableitung von "PartModificationProcessBase"). Der Eintrag in USysRegistry erfolgt programmatisch zusammen mit dem Eintrag in USysClass. Für die Grundlagen (KHKGruppen) verwenden wir den Typ 90000, für den Typ in Sammelmappen verwenden wir 90 (siehe Beschreibung in VBA-Aufrufe).

Wir codieren die Anzeige der Bezeichnung und das Ausblenden nicht verwendeter Register auf Basis von "PartModificationProcessBase" und legen die folgenden Metadaten an.

• Anlage des Master-Detail-Elementes "mdtProjektsteuerungSammelmappe"
  • "Titel" = "Sammelmappe Projektsteuerung"
  • "Titel Detailbereich" = "Projektsteuerung $[Parameter(Matchcode)]"
  • "Master-Detail-Typ" = "nur Detail-Elemente"
  • "Detail-Elemente"
    • "lstSMNotizen.Sage.System"
    • "lstSMDokumente1.Sage.System"
      • "Parameter für Anpassung" = "1;90000"
    • "lstSMDokumente2.Sage.System"
      • "Parameter für Anpassung" = "2;90000"
    • ...
    • "lstSMDokumente19.Sage.System"
      • "Parameter für Anpassung" = "19;90000"
    • "lstSMDokumente20.Sage.System"
      • "Parameter für Anpassung" = "20;90000"
  • "Anpassung durch DLL (Name)" = "Sagede.ADID.Projektsteuerung.RealTimeData.dll"
  • "Anpassung durch DLL (Klassenname)" = "Sagede.ADID.Projektsteuerung.RealTimeData.PartModification.Sammelmappe"
  • "für Wawi?" aktivieren

Es sind insgesamt 21 Listen-Elemente zu hinterlegen. Bei den Dokumenten stehen die "..." für die restlichen 16 Listen-Elemente.

Wählen Sie das Kontextmenü "Projektsteuerung" aus.

• Anlage des Kontextmenüeintrags "Sammelmappe"
  • "Funktionstitel" = "Sammelmappe"
  • "Funktionskurztitel" = "Sammelmappe"
  • "Position in Sortierung" = "7"
  • "Schaltflächenposition" = "7"
  • "Festlegung Aktivierung durch Feld" = "[_DialogState]="Edit""
  • "Tooltipp im deaktivierten Zustand" = "Dieser Eintrag steht bei neuen Datensätzen nicht zur Verfügung."
  • "Funktionsaufruf“ = "MakroStarten.Sage.System“
  • "Ausführen Makro" = Befehl: AuskunftÖffnen, Parameter 1: mdtProjektsteuerungSammelmappe.<partnerid>.<loesungid>, Parameter 2: Typ:=90;Schluessel:= [SteuerungId];Matchcode:= [Matchcode];Gruppe:=90000;Class:= "BPKProjektsteuerung";PartName:="mdtProjektsteuerungSammelmappe.<partnerid>.<loesungid>"
    
  • "für Wawi?" aktivieren

Frage: Sollen Daten eines bestehender Datensatzes auf einen neuen Datensatz kopiert werden können?

• Die Antwort ist Ja: Sie benötigen ein Kontextmenüeintrag mit dem Funktionsaufruf "DatensatzKopieren"
• Die Antwort ist Nein: Weiter mit Validierungen

Die Anforderung zum Kopieren lautet:

• Beim Kopieren von Daten sollen optional Mitarbeiter mit bzw. nicht mit kopiert werden. Die Planung der Mitarbeiter sollen nicht kopiert werden.

Wie im vorherigen Kapitel angedeutet, braucht man eine Datenklasse, wenn man das systemseitige Kopieren verwenden will. Die Datenklasse haben wir dort angelegt. Hier stellen wir jetzt die Verbindung her. Selektieren Sie das Feld "SteuerungId" des Datensatzes "recProjektsteuerung" und ändern Sie den Datentyp auf "Schlüssel 1 einer Datenklasse" und hinterlegen Sie in der Eigenschaft "Datenklasse" die neue Datenklasse "clsBPKProjektsteuerung.<ihre_partnerid>.<ihre_loesungid>". 

Beim systemseitigen Kopieren (Funktionsaufruf "DatensatzKopieren.Sage.System") wird nur der Hauptdatensatz kopiert. 1:N-Beziehungen können kopiert werden, aber nur per Abfrage (daher brauchen wir uns um die Planungen nicht zu kümmern, sie werden per Default nicht mitkopiert). Die Abfragen hinterlegt man in der Eigenschaft "Abfragen für Datensatzkopie" des Datensatzes. Hinterlegen Sie im Datensatz "recProjektsteuerung" in dieser Eigenschaft diese Werte:

• "Index" = "1"
• "Wert" = "auch Mitarbeiter kopieren"
• "Datensatz" = "recProjektsteuerungMitarbeiter.<ihre_partnerid>.<ihre_loesungid>"

 Es fehlt noch der Kontextmenüeintrag im Kontextmenü "Projektsteuerung".

• Anlage des Kontextmenüeintrags "Kopieren"
  • "Funktionstitel" = "Kopieren"
  • "Funktionskurztitel" = "Kopieren"
  • "Position in Sortierung" = "8"
  • "Schaltflächenposition" = "8"
  • "Gruppe beginnen?" aktivieren
  • "Festlegung Aktivierung durch Feld" = "[_DialogState]="Edit""
  • "Tooltipp im deaktivierten Zustand" = "Dieser Eintrag steht bei neuen Datensätzen nicht zur Verfügung."
  • "Funktionsaufruf" = "DatensatzKopieren.Sage.System"
  • "für Wawi?" aktivieren

Frage: Müssen Eingaben/Änderungen vor dem Speichern, oder das Löschen von Datensätzen validiert werden?

• Die Antwort ist Ja: Sie brauchen einen Makroaufruf und eine .Net-Assembly, die serverseitig ausgeführt wird.
• Die Antwort ist Nein: Die Erstellung des Stammdatendialoges ist abgeschlossen.

Folgende Anforderung an valide Daten gibt es:

• Die Felder Projektsteuerung, Projekt, Projektleiter und Kontakt sind Pflichtfelder.
• Die Bezeichnung der Projektsteuerung darf nach dem Speichern nicht mehr geändert werden.
• Projektsteuerungen mit offenen Vorgängen, oder hinterlegten Terminen können nicht gelöscht werden.
• Das Projekt kann nicht mehr geändert werden, wenn bereits Termine erfasst wurden.
• Ein Mitarbeiter darf nicht gelöscht werden, wenn er bereits einem Termin zugeordnet ist.

Wie bereits bei den Stammdaten "Projektthemen" dargestellt wurde, kann eine Validierung nur serverseitig erfolgen. Es gilt aber auch zu prüfen, ob man mit der Meldung beim Speichern zu spät kommt. Wir werden serverseitig prüfen, ob das Projekt geändert wurde, obwohl bereits mindestens ein Termin erfasst wurde. Das bedeutet, dass ein Anwender ein Projekt ändern kann, alle relevanten Daten erfasst und beim Speichern dann den Hinweis bekommt, dass das Projekt nicht mehr geändert werden darf. Wir werden also zusätzlich clientseitige Maßnahmen treffen, die den Ablauf der Datenerfassung verbessern.

Sämtliche Anforderungen werden codiert und in den Ereignissen "Vor Änderung" und "Vor Löschung" des Datensatzes "recProjektsteuerung" per Makrobefehl ausgeführt. Dabei brauchen wir die erste Anforderung nicht umsetzten. In den Metadaten sind diese Felder als "Pflichtfeld?" markiert. Das passierte beim Anlegen des Datensatzes bei dem Import der Tabelle, in der diese Felder mit NOT NULL definiert sind. Diese Prüfung (Pflichtfeld darf nicht leer sein) erfolgt serverseitig vom System.

Wir hinterlegen in den Ereignissen „Vor Änderung“ und „Vor Löschung“ des Datensatzes "recProjektsteuerung" folgende Makros (PartnerId und LösungId entsprechend Ihren Daten):

Ereignis "Vor Änderung“

Ereignis "Vor Löschung“

Wir hinterlegen in dem Ereignis „Vor Löschung“ des Datensatzes "recProjektsteuerungMitarbeiter" folgende Makros (PartnerId und LösungId entsprechen Ihren Daten):

Ereignis "Vor Löschung“

Mit dieser Codierung haben wir alle Validierungen implementiert.

Für den verbesserten Ablauf prüfen wir beim Anzeigen eines Datensatzes, ob Termine vorhanden sind und ob bereits Mitarbeiter in den Terminen hinterlegt wurden. Abhängig von dieser Prüfung werden die Löschen-Schaltfläche und die Felder "Projektbezeichnung" und "Projekt" freigeschaltet oder gesperrt.

Das Freischalten der beiden Felder "Projektbezeichnung" und "Projekt" können wir auf dem Client abfragen, da wir den Dialogstatus abfragen können. Ob Datensätze gelöscht werden können, können wir nur serverseitig prüfen. Die Makros hinterlegen wir im Ereignis "Beim Anzeigen" des Daten-Edit-Elementes "ediProjektsteuerung". Das Schalten des Kontextmenüeintrages "Löschen" können wir nur über ein Ausdruck steuern. Dafür benutzen wir ein schreibgeschütztes Feld. Folgende Metadaten sind anzulegen:

• Anlage des Feldes "CanDelete" im Datensatz "recProjektsteuerung"
  • "Datentyp" = "Boolean"
  • "Schreibschutz?" aktivieren
• Import des Feldes im Daten-Edit-Element "ediProjektsteuerung" im Register/Feldgruppe "Projektsteuerung/Projektsteuerung"
  • "Sichtbarkeit" = "Versteckt"
• Ergänzung der Eigenschaft "Festlegung Aktivierung durch Feld" des Kontextmenüeintrags "Loeschen" des Kontextmenüs "Projektsteuerung" um " AND [CanDelete] = True"

Wir codieren die serverseitige Prüfung. Hier wird der Wert für "CanDelete" gesetzt.

Jetzt hinterlegen wir die folgenden Makros im Ereignis "Beim Anzeigen".

Frage: Soll der Stammdatendialog an definierter Stelle aus dem Regiezentrum aufrufbar sein?

• Die Antwort ist Ja: Sie benötigen einen Eintrag unter „Oberfläche/ Regiezentrum“
• Die Antwort ist Nein: Die Erstellung des Stammdatendialoges „Projektsteuerung“ ist abgeschlossen

Laut Beispielbeschreibung soll der Stammdatendialog „Projektsteuerungen“ unter dem Menüpunkt „Projektthemen“ aufrufbar sein.

Wechsel Sie im AppDesigner auf „Oberfläche/ Regiezentrum“ und erstellen Sie den neuen Eintrag „mnuProjektsteuerungen“. Hinterlegen Sie folgende Eigenschaften:

Deaktivieren Sie die Lizenzoption „im Regiezentrum verfügbar?“ des Daten-Edit-Elementes „ediProjektsteuerung“.