CONZEPT 16-Prozeduren laufen standardmäßig mit Debugger-Unterstützung. Dabei wird im Hintergrund ein Protokoll für die Funktionsaufrufe angelegt. Dieser Debug-Modus wird eigentlich nur für die Entwicklung benötigt, daher gibt es die Möglichkeit, den Debug-Modus auszuschalten.
Mit Hilfe des Funktionsaufrufs DbgControl(_DbgOff) lässt sich der Debug-Modus ausschalten. Dies führt mit sich, dass alle Debugger-Befehle außer DbgControl(_DbgCallstackOn), DbgControl(_DbgCallstackOff) und DbgDump() ignoriert werden.
Darüber hinaus wird beim Ausschalten des Debug-Modus die Statusprotokollierung bei Funktionsaufrufen ausgeschaltet. Das heißt es werden weder externe noch interne Funktionsein- und austritte protokolliert. Das zieht zum Einen mit sich, dass die Geschwindigkeit der Applikation erhöht wird, was das Laufzeitverhalten verbessert. Zum Anderen lassen sich dann die Prozedurinformationen aus den Systemeigenschaften spProcCurrent, spProcCurrentSub, spProcCurrentFull nicht mehr auslesen, jedoch kann man für dieselben Informationen die vordefinierten Makros verwenden.
Der Hauptvorteil dieser Option besteht darin, dass man sich 100%-ig sicher sein kann, dass Debug-Befehle nicht mehr ausgeführt werden. Es kann immer wieder mal passieren, dass man im Prozedurcode die ein oder andere Debug-Funktion vergisst, im schlimmsten Fall ein DbgStop(). Daher empfehlen wir für Applikationen, die für den Endanwender gedacht sind, diese Option zu setzen.
2 Antworten
Um den Fehlerkontext innerhalb der mit ErrCall() definierten Funktion festzustellen, sind andere Eigenschaften des System-Objektes zu verwenden:
spErrCode – Fehlercode des Laufzeitfehlers
spErrText – Text der Fehlermeldung
spErrProc – Prozedurfunktion, in der der Fehler aufgetreten ist
spErrLine – Programmzeile, in der der Fehler aufgetreten ist
spErrSource – Name der Include-Prozedur
Details finden Sie auch unter http://blog.conzept16.de/2012/03/Laufzeitfehler-finden.
Diese Eigenschaften werden durch DbgControl(_DbgOff) nicht beeinflusst.
das hat aber den schweren Nachteil, das man bei auftretenden Laufzeitfehlern in einer per ErrCall() definierten
Prozedur keine Informationen mehr über die Stelle, an der der Fehler aufgetreten ist, auslesen und weitermelden kann.