Peter, sqlYoga does the same thing. What he recommends is having the end dev wrapping calls to his library in a try catch structure, and reporting the error in the catch section. It works really well for me that way. I'm not sure if he has a way of returning errors in a more meaningful way, or if the LC engine is just returning the error that is generated. But the try/catch will prevent the debugger from triggering in any event.
Bob On Sep 12, 2012, at 12:35 PM, Peter Haworth wrote: > I guess I should explain a bit more in my interest in this. > > My lcStackBrowser plugin uses a front script in a button in a password > protected stack with handlers for several messages to do with new objects. > If a user is in debug mode in one of his stacks and his code happens to > trigger one of the handlers in my front script, debug tries to put him into > that handler and prompts for the password which he doesn't have so > everything hangs up at that point. > > So I guess my interest is if I can utilize the mechanism by which the IDE > protects its handlers from being seen by debug for my own stacks to avoid > this issue. I was hoping perhaps there would be a secret custom property > that told debug to keep out or something like that. > > Alternativley, I can simply not password protect the stack - there's really > not much I care about protecting in there. > > Pete > lcSQL Software <http://www.lcsql.com> > > > > On Wed, Sep 12, 2012 at 12:13 PM, Mark Wieder <mwie...@ahsoftware.net>wrote: > >> Peter Haworth <pete@...> writes: >> >>> >>> When I'm stepping through my code in debug and I step into a call to an >>> engine command or function, the debugger simply goes to the next >> statement >>> in my code not to the engine code. >>> >>> Does anyone know the mechanism by which the code of engine >>> commands/functions is ignored by the debugger? >> >> That's by design to keep you out of trouble in endless loops, etc. If that >> doesn't bother you and you won't lose unsaved work you can do a >> >> global gRevDevelopment; put true into gRevDevelopment >> >> from the messagebox. And put false back in there when you're done playing >> around >> in the system stacks. >> >> Note: this will also reveal bugs in the IDE stacks, so ignorance may be >> bliss. >> >> -- >> Mark Wieder >> mwie...@ahsoftware.net >> >> >> _______________________________________________ >> 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
