Debug and IDE scripts

[Peter Haworth]

I'm already doing that.  The problem is that the front script is password
protected so debug prompts for the password as soon as the engine sends the
message before I get a chance to do anything.
Pete
lcSQL Software <http://www.lcsql.com>



On Wed, Sep 12, 2012 at 2:09 PM, Bob Sneidar <bobs at twft.com> wrote:

> Oh I see sorry, I was thinking in terms of a faceless library. I would say
> then, and you won't want to hear this, but put all your protected code in a
> library, and password protect that. Then make calls to your library from
> your front end using try/catch. Have your own error handling mechanism to
> deal with the problem cleanly, like closing the lcStackBrowser interface if
> an error occurs. Might be too much to have to rewrite the interface though.
>
> Bob
>
>
> On Sep 12, 2012, at 1:52 PM, Peter Haworth wrote:
>
> > 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
> >>
> > _______________________________________________
> > 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
>