On 09/02/2015 07:50 PM, J. Landman Gay wrote:
Today I finally saw my first instance of a pirate red dot breakpoint
that didn't meet my previous criteria. I am initiated. This was in LC
7.0.6 which I have just started using more regularly. Prior to 7.x I had
never seen it happen except when a script called into an IDE library.
The way the IDE's script editor handles these ephemeral breakpoints is
pretty screwy. That's my story and I'm sticking to it.
The breakpoints are stored in one of two places: as a custom property of
the preferences file if you're dealing with a global variable, or as a
custom property of the owning stack if it's a local variable. The
breakpoint is stored as objectID, lineNumber.
Breakpoint conditions are also stored as custom properties in the same
places, but are stored as expression. There is no other context for the
condition, it's just supposed to be indexed from the breakpoint list.
Thus you can have
breakpoints:
button 1003 of card 1002, 14
button 1042 of card 1003, 7
breakpointConditions
x > 4
y = 5
If these get out of sync (you remove a condition, you have an error in
your code that prevents the list from getting updated, etc) then they no
longer match up and you have orphans.
Worse, since the conditions have no sense of scope, they will trigger
when any handler in the indexed object meets that condition, i.e., even
when the lists are synced properly, any handler in button 1003 will
trigger the 'x > 4' condition if it contains an x variable.
--
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
