modal window = block handler?

[Lagi Pittas]

I second that emotion.

And this shouldn't  cause any regressions or refactoring - should be
announced  by thursday then? ;-)

Lagi

On 10 July 2017 at 22:53, Paul Dupuis via use-livecode <
use-livecode at lists.runrev.com> wrote:

> On 7/10/2017 4:54 PM, J. Landman Gay via use-livecode wrote:
> > On 7/10/17 3:41 PM, J. Landman Gay via use-livecode wrote:
> >> On 7/10/17 12:18 PM, FlexibleLearning.com via use-livecode wrote:
> >>> Opening a modal as normal (i.e. visible) obviously still does what you
> >>> specify. We simply have a 'hidden feature' that enables a
> >>> non-blocking modal
> >>> should it be required (e.g. a progress indicator that prevents
> >>> user-clicks
> >>> on other windows).
> >>
> >> This is no longer true and affects all stacks that require a modal to
> >> block other windows. "Modal" should mean no other actions are
> >> possible until the modal is dismissed.
> >>
> >> The command: modal "stackname" allows the user to click on another
> >> window and bring it to the front, and then proceed normally as though
> >> the modal didn't exist.
> >>
> >
> > I've added a test stack and comment to
> > http://quality.livecode.com/show_bug.cgi?id=14275
> >
>
> Whatever LiveCode chooses to call them, as developer I (and I think
> "we") need TWO behaviors for modal windows:
>
> 1) present the window and halt the current script on the line that
> presented the window and prevent any other scripts or actions from
> executing until that is closed
>
> 2) present a modal windows, allow no other scripts or actions to occur,
> but allow the current handler to continue executing.
>
> This would allow for traditional modal dialogs (1) and modal progress
> indicators (2)
>
>
>
> _______________________________________________
> 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
>