In some of my projects, I have a handler in my stack script to help with
this. It requires one extra click (to step out of th handler) - but I
often find it's worth that for the other advantages.
The minimalist version is
on mybreakpoint
breakpoint
end mybreakpoint
while the fancier version is more like:
on mybreakpoint pLevel
if pLevel < gBreakLevel then exit mybreakpoint
put item -2 to -1 of line -2 of the executioncontexts &CR after msg
repeat with i = 1 to paramcount()
if param(i) is an array then
printarray i, param(i)
else
put i &"::" & param(i) & "::" &CR after msg
end if
end repeat
breakpoint
end mybreakpoint
I don't have it in a standard library because I tend to customize what
it does, whether it logs calls to a file, etc. as I go ...
Sometimes I use a "level" fpr whether or not to break, other teims I
name each call, and have a (global) list of named calls that should
actually break, etc.
Alex.
On 27/12/2018 22:34, J. Landman Gay via use-livecode wrote:
Yeah, I know breakpoints don't hurt in standalones but during active
debugging you have to keep moving them around or deleting them to
avoid unintended breaks. At least with red dots you can zap them all
at once with a menu selection.
I've had more than one brush with the law you mentioned. :)
--
Jacqueline Landman Gay | jac...@hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
On December 27, 2018 3:40:31 PM Mark Wieder via use-livecode
<use-livecode@lists.runrev.com> wrote:
On 12/27/18 10:21 AM, J. Landman Gay via use-livecode wrote:
I've heard you can insert hard-coded breakpoint commands in the script
instead but I haven't tried that yet. (Then you need to track them down
and remove them when they are no longer needed.)
If you don't have remote debugging enabled then hard-coded breakpoints
in a standalone app should have (almost) no effect. The mechanism in the
engine that triggers breaks will fire, but if nothing is there to catch
it then execution will continue as if nothing happened.
That said, it's probably good practice to remove them before shipping
anyway because of the Law of Unintended Consequences.
--
Mark Wieder
ahsoftw...@gmail.com
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your
subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
