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 <b...@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 <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 > > > _______________________________________________ > 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
