Debug and IDE scripts

[Peter Haworth]

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 <bobs at 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 <mwieder at ahsoftware.net
> >wrote:
> >
> >> Peter Haworth <pete at ...> 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
> >> mwieder at ahsoftware.net
> >>
> >>
> >> _______________________________________________
> >> 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
>
>
> _______________________________________________
> 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
>