Debug and IDE scripts

[Bob Sneidar]

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