Thanks Bob. Problem is these are messages that are issued by the engine,. not me. For example, my front script contains a newStack handler so any time a new stack is created in the IDE, code in the engine sends a newStack message which is trapped by my front script. I have no control over how the engine sends that message so can't puyt it in a try/catch. Pete lcSQL Software <http://www.lcsql.com>
On Wed, Sep 12, 2012 at 1:42 PM, Bob Sneidar <b...@twft.com> wrote: > 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 > _______________________________________________ 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
