I see where your thinking comes from, but it's not a bug. It might be more accurate if the instruction were called 'DisableDebuggerUpdates' but this is more cumbersome and also not entirely accurate either.
Compare with the behaviour of this variant. The 'Debugger is still on' messages won't be displayed in this example and this program won't break at the CallDebugger breakpoint either.
Code: Select all
PurifierGranularity(0, 0, 0, 0); just in case DisableDebugger doesn't disable Purifier
Debug "Hello!"
DisableDebugger
Debug "Debugger is still on 1."
CallDebugger
CompilerIf #PB_Compiler_Debugger
Debug "Debugger is still on 2."
CompilerEndIf
Procedure err()
MessageRequester("error", ErrorMessage(), #PB_MessageRequester_Error)
End
EndProcedure
OnErrorCall(@err()); will never be called because debugger will still catch it first
PokeS(0, "test"); will trigger the debugger warning/error
The debugging tools take
time to update. So for example it takes time for the Variable Viewer to be updated, the Data Breakpoint tool to check if a break is needed, to update the Watchlist or the Debug output window. DisableDebugger stops these updates occurring so the code in these sections
should run faster. This
isn't always true though, but it will be true if you're using several Data Breakpoints for example. It also stops code stepping which is tedious in big loops.
The program is still running under the control of the IDE though so it will trap any fatal runtime errors so the error can be displayed, and the error you're simulating is a fatal one. Your error handler will be called properly when a fully standalone executable is published.