Debug and IDE scripts

Peter Haworth pete at lcsql.com
Wed Sep 12 18:26:23 EDT 2012


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
>



More information about the use-livecode mailing list