The JADE 2022 release meets tomorrow’s business demands.
Guest
|
HistoricalComments
Brian Johnstone 2/10/2017 9:26:25 AM
Whilst not automated, which would be nice if it was possible to implement, I use the workflow of disabling that breakpoint in the debugger's list of breakpoints before continuing the execution. Then, once the stack is "idle" again I enable the breakpoint. It does mean remembering to swap back to the debugger to do the enable on the relevant breakpoint, but at least you can quickly get through the remaining times it would have stopped on the breakpoint in question without having to repeatedly continue execution. Alternately, if I know the condition under which I want to stop, I'll make the breakpoint conditional instead of always stopping. Blake De?Ath 29/09/2017 2:29:52 PM Might pay to correct your suggestion then. Software Medical Infomatics Limited 28/09/2017 9:48:33 AM Sorry, my analogy is reversed - I mean the bottom of the call stack - i.e. back to idle, waiting for the next event before the breakpoint is active again. Ty Baen-Price 26/09/2017 9:23:12 AM There is an amount of control like this available from the Breakpoints form in the debugger. Can you explain what you mean by "ignore the breakpoint until the top of the call stack"? If you're at a break point, you are at the top of the call stack... |
