Musings on Architect, MVC, Nested Behaviors

[Alex Tweedly]

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 | jacque at hyperactivesw.com
> HyperActive Software | http://www.hyperactivesw.com
> On December 27, 2018 3:40:31 PM Mark Wieder via use-livecode 
> <use-livecode at 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
>>  ahsoftware at gmail.com
>>
>> _______________________________________________
>> use-livecode mailing list
>> use-livecode at 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 at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your 
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode