Errorhandling inside DCBROWSECOLs
Posted: Fri Apr 09, 2010 5:44 am
Hi, Roger.
I found this code in _DCXBROW.PRG:
This means that the standard error system or the error system of the app is inactive during "ForceStable".
The :ForceStable method is not only called directly (from my code), but implicit several times (in my opinion during browse creation and refresh calls).
Your code (above) leads to the situation that errors inside functions called using the itemmarked-slots, but also code used inside color-codeblocks (!) do not lead to a runtime error. Wrong color-codeblocks create wrong browse layouts (missing cells, missing rows, no navigation), but no errors (I can create a sample if you need one). This makes debugging difficult in those cases. Errors inside itemmarked-codeblocks sometimes call the DC-error system, but not the runtime error system of the app.
Is this something you left inside from earlier days?
Tom
I found this code in _DCXBROW.PRG:
Code: Select all
METHOD DC_XbpBrowse:forceStable()
LOCAL bErrorBlock := ErrorBlock({|e|_TrapErrors(e)})
BEGIN SEQUENCE
::XbpBrowse:forceStable()
END SEQUENCE
ErrorBlock(bErrorBlock)
RETURN selfThe :ForceStable method is not only called directly (from my code), but implicit several times (in my opinion during browse creation and refresh calls).
Your code (above) leads to the situation that errors inside functions called using the itemmarked-slots, but also code used inside color-codeblocks (!) do not lead to a runtime error. Wrong color-codeblocks create wrong browse layouts (missing cells, missing rows, no navigation), but no errors (I can create a sample if you need one). This makes debugging difficult in those cases. Errors inside itemmarked-codeblocks sometimes call the DC-error system, but not the runtime error system of the app.
Is this something you left inside from earlier days?
Tom