Re: modal window = block handler?

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@lists.runrev.com> wrote: > On 7/10/2017 4:54 PM, J. Landman Gay via use-livecode wrote: > > On

Re: modal window = block handler?

I realize that, but this thread has been discussing whether that is a "bug" or not. I support that there should be a feature, but probably a MORE clearly identified feature. Something LIKE (I am not proposing specific syntax, but illustrating a point) open window "X" as modal paused and open

Re: modal window = block handler?

According to this thread, that is what open invis as modal does. Bob S > On Jul 10, 2017, at 14:53 , Paul Dupuis via use-livecode > wrote: > > 2) present a modal windows, allow no other scripts or actions to occur, > but allow the current handler to continue

Re: modal window = block handler?

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

Re: modal window = block handler?

err... will NOW work? Bob S > On Jul 10, 2017, at 14:08 , Bob Sneidar via use-livecode > wrote: > > Okay, this has piqued my curiosity. Are you saying that if I open a stack > invisible as modal, I can then show that stack later and animated progress >

Re: modal window = block handler?

Okay, this has piqued my curiosity. Are you saying that if I open a stack invisible as modal, I can then show that stack later and animated progress indicators will not work?? Bob S > On Jul 10, 2017, at 13:51 , FlexibleLearning.com via use-livecode > wrote:

Re: modal window = block handler?

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

RE: modal window = block handler?

to use LiveCode <use-livecode@lists.runrev.com> Cc: FlexibleLearning.com <ad...@flexiblelearning.com> Subject: Re: modal window = block handler? Friends, Just to add a related note here, at least on 9dp5 the "popup" command is also not pausing. It is supposed to pause

Re: modal window = block handler?

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

Re: modal window = block handler?

EEEK! > On Jul 10, 2017, at 11:15 , Andre Garzia via use-livecode > wrote: > > Friends, > > Just to add a related note here, at least on 9dp5 the "popup" command is > also not pausing. It is supposed to pause the handler that calls it until > menupick happens

Re: modal window = block handler?

Friends, Just to add a related note here, at least on 9dp5 the "popup" command is also not pausing. It is supposed to pause the handler that calls it until menupick happens but in my experience here it simple keeps running even while the modal is open. This might be related. om om andre On

Re: modal window = block handler?

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). Hugh Senior FLCo > I'm going to have to disagree here.

Re: modal window = block handler?

lesson learned .. happy i found out about this inconcistency now rather than later. going forward I am using a "wait until mywindowopen = 0 with messages" to make sure i get the same identical behavior on every platform. thanks as always you guys On Mon, Jul 10, 2017 at 11:18 AM, Bob

Re: modal window = block handler?

Of course, modal windows do not "halt code execution" in that sense. They could not because you would not be able to use any code in front or back scripts. They prevent the calling handler from proceeding. It's like inserting blocking code where the modal is called. Bob S > On Jul 10, 2017,

Re: modal window = block handler?

A related issue I ran into recently: I had a complex modal dialog. In my code for the dialog controls I was calling a routine that had a "wait 0 with messages" statement. I discovered that the wait ... with messages allows user events (for example commandKeyDown, etc.) to kick off other scripts

Re: modal window = block handler?

I'm going to have to disagree here. I open windows modally for the specific purpose of halting code in the calling stack until the modal window is dismissed so that I can proceed with input from the user. An Answer dialog is simply a modal stack if I am not mistaken. It's interesting though

Re: modal window = block handler?

If you open invisible, then display it, a modal will not block. This non-modal behaviour of a modal has been incredibly useful for displaying a progress indicator in a modal window. I do not consider it a bug as such (modal blocks underlying windows, not necessarily code), and would hope this

Re: modal window = block handler?

Tom Glod wrote: > omg its actually doing it ... the correction to the type did not > solve it. > > its continuing to run the handler after the stack is opened as modal. > > not good. Does it help if you change: open stack "MyStack" as modal ...to: modal "MyStack" ? - rg

Re: modal window = block handler?

no spotify On Sun, Jul 9, 2017 at 4:12 PM, Tom Glod wrote: > omg its actually doing it ... the correction to the type did not solve it. > > its continuing to run the handler after the stack is opened as modal. > > not good. > > On Sun, Jul 9, 2017 at 4:08 PM, Tom Glod

Re: modal window = block handler?

omg its actually doing it ... the correction to the type did not solve it. its continuing to run the handler after the stack is opened as modal. not good. On Sun, Jul 9, 2017 at 4:08 PM, Tom Glod wrote: > its on windows.i did a workaround for it . > for sure it was

Re: modal window = block handler?

its on windows.i did a workaround for it . for sure it was continuing the handler after opening the window .. BUT i did find that there was a space missing between the name of the stack and "as modal" i didn't get an error from the engine ...so i never notice it before. i haven't gone

Re: modal window = block handler?

Read further I am not using spotify. Bob S > On Jul 9, 2017, at 12:05 , Bob Sneidar via use-livecode > wrote: > > That is remarkable. I am running V8 and modal windows work for me. Put a > brealpoint right aftr the call to the modal stack and see if the

Re: modal window = block handler?

That is remarkable. I am running V8 and modal windows work for me. Put a brealpoint right aftr the call to the modal stack and see if the breakpoint triggers. Bob S > On Jul 9, 2017, at 08:49 , Tom Glod via use-livecode > wrote: > > Hi everyone, i only

Re: modal window = block handler?

Out of curiosity: Is this on a Mac? Do you have Spotify open? http://quality.livecode.com/show_bug.cgi?id=14275 Cheers, Malte ___ use-livecode mailing list use-livecode@lists.runrev.com Please