Speaking of modals...

[Peter Haworth]

My trick for debugging a modal stack is to open it as a palette instead of
modal and stick a breakpoint right after the code that opens it.  The stack
opens up and execution stops at the breakpoint so you can easily go through
whatever functions the stack performs and find any problems.

On Fri, Mar 20, 2015 at 2:01 PM Bob Sneidar <bobsneidar at iotecdigital.com>
wrote:

> One caveat however is that if the script that opened the modal stack has
> more commands pending, they will execute as soon as the stack is re-opened
> non-modally.
>
> Bob S
>
>
> > On Mar 20, 2015, at 13:56 , Bob Sneidar <bobsneidar at iotecdigital.com>
> wrote:
> >
> > I take this back. I had a bug in my unModal handler. Turns out this
> works a peach! I have a front script with this handler in it:
> >
> > on unModal theStack
> >   lock messages
> >   save stack theStack
> >   close stack theStack
> >   open stack theStack
> >   unlock messages
> > end unModal
> >
> > I then have a Debug menu in the moralized stack which has this in the
> menuPick:
> >
> > on menuPick pWhich
> >   switch pWhich
> >      case "Demodalize"
> >         put the short name of this stack into thisStack
> >         unmodal thisStack
> >         break
> >   end switch
> > end menuPick
> >
> > Bob S
> >
> >
> >> On Mar 20, 2015, at 13:50 , Bob Sneidar <bobsneidar at iotecdigital.com>
> wrote:
> >>
> >> To answer my own question, don’t try to close a stack then reopen it
> while opened modally. It will hard lock Livecode. I’m wondering if there is
> a property of a stack that can be set then.
> >>
> >> Bob S
> >
>
> _______________________________________________
> 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