Folgende Benutzer bedankten sich beim Autor Lucyalison für den Beitrag:
Bright4.5
Ja.
Da geht es am einfachsten, aber ist vielleicht nicht für jeden Anwendungsfall brauchbar. Die Philosophie hinter den Schnittstellen vs. Formular ist, dass alles was zur Vorbereitungs der Daten für den Ausdrucks benötigt wird in der Schnittstelle erfolgen soll. Zum Beispiel umwandeln von Werten in ein besser lesbares Format. Das Lesen der Daten gehört da eigentlich nicht dazu, denn das sollte durch das aufrufende Druckprogramm erfolgen.Bright4.5 hat geschrieben: ↑08.05.2020 14:40Da ich aus einer DB-Tabelle prüfen möchte um welches Material es sich handelt und dann den dementsprechenden Feldinhalt nehmen möchte, sollte ich noch eine Abfrage programmieren. Sollte das in der Schnittstelle unter der Rubrik Coding-Initialisierung erfolgen(siehe Bild)?
Wenn du da fündig wirst, gib mir bitte Bescheid 😉
Ich setzt mir dafür meist einen Breakpoint entweder in den generierten Funktionsbaustein des Formular oder in einen der FPCOMP_FORM_* Bausteine.
In der Schnittstelle kannst du leider nur Datentypen aus dem Dictionary angeben. D.h. deine Logik funktioniert leider nicht.So nun hätte ich eine Idee und zwar ich erstelle mir in dem Teil "Coding Initialisierung" in der Schnittstelle eine neue interne Tabelle mit der gleichen Struktur wie die bisherige interne Tabelle + das eine Feld und lass mir die interne Tabelle übertragen und pflege das Feld nach.
Folgende Benutzer bedankten sich beim Autor Aba für den Beitrag:
Bright4.5
Entweder mit einem harten BREAK(-POINT) im Coding oder mit einem dynamischen Break-Point im generierten Funktionsbaustein (Form-Routine %GLOBAL_INIT).