On 9/2/2015 10:10 PM, Mark Wieder wrote:
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.
Interesting, thanks for that. So if I hit one of these phantom orphaned dots it seems logical that clearing all breakpoints (from the Debug menu) would reset everything and put me back in business. I'll try it next time.
-- Jacqueline Landman Gay | jac...@hyperactivesw.com HyperActive Software | http://www.hyperactivesw.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
