BC Debug: Unterschied zwischen den Versionen

Aus bafbal.de
Zur Navigation springen Zur Suche springen
 
(2 dazwischenliegende Versionen desselben Benutzers werden nicht angezeigt)
Zeile 12: Zeile 12:
  
 
Es folgen ein Label (auch mit einer übersetzten Beschriftung) und ein Edit-Feld, danach wird die Prozedur ''#filter'' aufgerufen, welche das Filter-Kommando des Formulars ausführt.
 
Es folgen ein Label (auch mit einer übersetzten Beschriftung) und ein Edit-Feld, danach wird die Prozedur ''#filter'' aufgerufen, welche das Filter-Kommando des Formulars ausführt.
 +
 +
Die Ausführung des Kommandos ''xlookup_flt'' beginnt damit, dass der Baum geleert wird. Dann wird geprüft, ob ''edt1'' einen Inhalt hat. An dieser Stelle sind zwei Funktionen ineinander geschachtelt. Zuerst wird die innere Funktion $EDT() ausgeführt, diese gibt einen leeren String zurück. Mit $NEMPTY() wird geprüft, dass der Inhalt von ''edt1'' nicht leer ist - da er leer ist, wird ''N'' zurück gegeben.
 +
 +
Es wird also zur nächsten Verzweigung gesprungen, diese ist ohne Bedingung, wird also immer ausgeführt, wenn keine vorherige Bedingung zugetroffen hat. Hier wird mittels eines SQL-Statements der Baum gefüllt.
 +
 +
Jeder Tab im BAF-Client hat einen korrespondierenden Tab im Debug-Log. Aus Gründen der Performance und der Übersichtlichkeit wird das Log nur geschrieben, wenn es ''Aktiv'' ist. Mit ''Clear Log'' lässt es sich auch löschen. Mit ''StayOnTop'' wird das Formular des Debug-Fensters immer im Vordergrund angezeigt.
 +
 +
==Upsert==
 +
 +
Datenänderungen in den Formularen werden intern über so genannte Upsert-Prozeduren an die Datenbank gegeben. Die Prozedur #upsert kann auch aus dem Code heraus aufgerufen werden. Wird das Debug-Fenster ''Upsert'' aktiviert, dann wird vor der Ausführung die Ini-Datei mit den Daten gezeigt (in diesem Format geht das zur weiteren Ausführung). Mittels der beiden Button kann dann entschieden werden, ob die Prozedur ausgeführt werden oder übersprungen werden soll.
 +
 +
[[file:debug upsert.png|800px|Upsert]]
 +
 +
Die eigentlichen Daten werden im Bereich ''[Data]'' dargestellt. Da wir hier eine Datenänderung haben, sehen wir hier nur den Inhalt des geänderten Feldes (hier ''description'') sowie die ID des Datensatzes.
 +
 +
Oben sehen wir den Namen der Tabelle (''t''), den Namen der Schlüssel-Spalte (''k''), ob der Datensatz zu Historisieren ist (die Historisierung selbst erfolgt über Trigger, aber es werden Werte für ''datechg'', ''usrchg'' und ''progchg'' hinzugefügt oder eben nicht). Der Eintrag ''ins'' hat hier den Wert 0, es wird dann daraus ein UPDATE-Statement gemacht, es folgt der Wert für die Schlüsselspalte (''kv'', also ''key value'').
 +
 +
==Select und Exec==
 +
 +
Die Debug-Fenster für Select und Exec lassen sich getrennt aktivieren. Sie werden dann immer dann geöffnet, wenn eine Select-Statement beziehungsweise ein anderes Statement ausgeführt wird.
 +
 +
[[file:debug select.png|800px|Select]]
 +
 +
Neben dem Statement werden auch die Werte für die einzelnen Parameter angezeigt. Mittels der Buttons kann entschieden werden, ob das Statement ausgeführt oder übersprungen werden soll. Soll die Anzeige der Statements abgebrochen werden, ist die Option ''Debug Select'' zu deaktivieren.
 +
 +
==NodeIni==
 +
 +
Hinter jedem Eintrag des Trees liegt ein String im Ini-Format, der einige Daten beinhaltet. Mit dem Debug-Fenster NodeIni kann diese Ini-Datei eingesehen werden.
 +
 +
[[file:debug node.png|800px|NodeIni]]
 +
 +
Im Datenbereich dieser Ini werden immer der Wert für das Schlüsselfeld - im Beispiel ''data_list_id'' - sowie die Werte für die beiden Beschriftungsfelder c1 und c2 gespeichert. Es können weitere Felder hinzugefügt werden. Im Abschnitt [Data] werden dabei die aktuellen Daten gespeichert - die auch von der Page geändert werden können - während im Abschnitt [DB] die Originalen, aus der Datenbank geladenen Werte gespeichert sind. (Auf diese Weise ist bei einem #cancel kein erneuter Datenbankzugriff erforderlich.)
 +
 +
Im Abschnitt [Additional] werden weitere Daten gespeichert, insbesondere
 +
* table - die Tabelle, aus der die Daten bezogen wurden; das wird benötigt für die Aktualisierung der Daten durch die Page, die nur dann erfolgt, wenn Tabellen- und Spaltennamen übereinstimmen
 +
* sel ("Select") - das Kommando, das ausgeführt wird, wenn der Eintrag selektiert wird; üblicherweise wird dann mit #page_fill die Page mit Daten gefüllt
 +
* open - das Kommando, das ausgeführt wird, wenn der Baumeintrag expandiert wird; auf diese Weise lassen sich dynamisch Daten nachladen
 +
* k ("Key") - der Spaltenname der Schlüsselspalte
 +
* c1 / c2 ("Caption") - die beiden Spaltennamen für die Beschriftung des Baumeintrags
 +
 +
Mit den beiden ''Code''-Buttons kann in das Code-Fenster gesprungen werden - mit ''Code Select'' direkt zum Select-Kommando, mit ''Code Open'' zum Open-Kommando. Auf diese Weise sind diese Code-Stellen besonders schnell auffindbar.

Aktuelle Version vom 9. August 2021, 20:31 Uhr

Die Debug-Tools

Oben links im Developement-Bereich sind die fünf Debug-Tools.

Debug-Log

Das Debug-Log zeigt die einzelnen Prozeduren in der Reihenfolge der Ausführung und die ausgeführten Funktionen inklusive deren Ergebnis an. Im Gegensatz zu einem konventionellen Debugger, bei dem man den Code Schritt für Schritt ausführt, lässt man beim Debug-Log das Programm einfach auf den Fehler laufen und schaut sich dann an, wie es dazu gekommen ist. Das hat sich in der Praxis als deutlich schneller herausgestellt.

Debug-Log

Hier im Beispiel sehen wir oben zunächst noch den Rest einer Funktion, $T(Add_list). Es wird also ein Text übersetzt. Das Ergebnis der Funktion wird nach den vier Minuszeichen angezeigt, Liste hinzufügen, es ist also Deutsch als Sprache eingestellt.

Es folgen ein Label (auch mit einer übersetzten Beschriftung) und ein Edit-Feld, danach wird die Prozedur #filter aufgerufen, welche das Filter-Kommando des Formulars ausführt.

Die Ausführung des Kommandos xlookup_flt beginnt damit, dass der Baum geleert wird. Dann wird geprüft, ob edt1 einen Inhalt hat. An dieser Stelle sind zwei Funktionen ineinander geschachtelt. Zuerst wird die innere Funktion $EDT() ausgeführt, diese gibt einen leeren String zurück. Mit $NEMPTY() wird geprüft, dass der Inhalt von edt1 nicht leer ist - da er leer ist, wird N zurück gegeben.

Es wird also zur nächsten Verzweigung gesprungen, diese ist ohne Bedingung, wird also immer ausgeführt, wenn keine vorherige Bedingung zugetroffen hat. Hier wird mittels eines SQL-Statements der Baum gefüllt.

Jeder Tab im BAF-Client hat einen korrespondierenden Tab im Debug-Log. Aus Gründen der Performance und der Übersichtlichkeit wird das Log nur geschrieben, wenn es Aktiv ist. Mit Clear Log lässt es sich auch löschen. Mit StayOnTop wird das Formular des Debug-Fensters immer im Vordergrund angezeigt.

Upsert

Datenänderungen in den Formularen werden intern über so genannte Upsert-Prozeduren an die Datenbank gegeben. Die Prozedur #upsert kann auch aus dem Code heraus aufgerufen werden. Wird das Debug-Fenster Upsert aktiviert, dann wird vor der Ausführung die Ini-Datei mit den Daten gezeigt (in diesem Format geht das zur weiteren Ausführung). Mittels der beiden Button kann dann entschieden werden, ob die Prozedur ausgeführt werden oder übersprungen werden soll.

Upsert

Die eigentlichen Daten werden im Bereich [Data] dargestellt. Da wir hier eine Datenänderung haben, sehen wir hier nur den Inhalt des geänderten Feldes (hier description) sowie die ID des Datensatzes.

Oben sehen wir den Namen der Tabelle (t), den Namen der Schlüssel-Spalte (k), ob der Datensatz zu Historisieren ist (die Historisierung selbst erfolgt über Trigger, aber es werden Werte für datechg, usrchg und progchg hinzugefügt oder eben nicht). Der Eintrag ins hat hier den Wert 0, es wird dann daraus ein UPDATE-Statement gemacht, es folgt der Wert für die Schlüsselspalte (kv, also key value).

Select und Exec

Die Debug-Fenster für Select und Exec lassen sich getrennt aktivieren. Sie werden dann immer dann geöffnet, wenn eine Select-Statement beziehungsweise ein anderes Statement ausgeführt wird.

Select

Neben dem Statement werden auch die Werte für die einzelnen Parameter angezeigt. Mittels der Buttons kann entschieden werden, ob das Statement ausgeführt oder übersprungen werden soll. Soll die Anzeige der Statements abgebrochen werden, ist die Option Debug Select zu deaktivieren.

NodeIni

Hinter jedem Eintrag des Trees liegt ein String im Ini-Format, der einige Daten beinhaltet. Mit dem Debug-Fenster NodeIni kann diese Ini-Datei eingesehen werden.

NodeIni

Im Datenbereich dieser Ini werden immer der Wert für das Schlüsselfeld - im Beispiel data_list_id - sowie die Werte für die beiden Beschriftungsfelder c1 und c2 gespeichert. Es können weitere Felder hinzugefügt werden. Im Abschnitt [Data] werden dabei die aktuellen Daten gespeichert - die auch von der Page geändert werden können - während im Abschnitt [DB] die Originalen, aus der Datenbank geladenen Werte gespeichert sind. (Auf diese Weise ist bei einem #cancel kein erneuter Datenbankzugriff erforderlich.)

Im Abschnitt [Additional] werden weitere Daten gespeichert, insbesondere

  • table - die Tabelle, aus der die Daten bezogen wurden; das wird benötigt für die Aktualisierung der Daten durch die Page, die nur dann erfolgt, wenn Tabellen- und Spaltennamen übereinstimmen
  • sel ("Select") - das Kommando, das ausgeführt wird, wenn der Eintrag selektiert wird; üblicherweise wird dann mit #page_fill die Page mit Daten gefüllt
  • open - das Kommando, das ausgeführt wird, wenn der Baumeintrag expandiert wird; auf diese Weise lassen sich dynamisch Daten nachladen
  • k ("Key") - der Spaltenname der Schlüsselspalte
  • c1 / c2 ("Caption") - die beiden Spaltennamen für die Beschriftung des Baumeintrags

Mit den beiden Code-Buttons kann in das Code-Fenster gesprungen werden - mit Code Select direkt zum Select-Kommando, mit Code Open zum Open-Kommando. Auf diese Weise sind diese Code-Stellen besonders schnell auffindbar.