Hey friends... of course when I say about stop the flow of code, I
mean to stop the flow of code that called the window, the flow would
be passed to the window being drawn, the internal events of window,
etc, etc, when I close the window, the flow should go back to the
point that called the modal window... like "call a function"
ex:
var a = 2;
var b = a + 2;
CallWindow();
// I don't want etc() to be executed until I close the window :-)
etc();
etc2();
c = a + b;
etc...
On Nov 15, 1:22 am, Brice Burgess <[EMAIL PROTECTED]> wrote:
> Wagner,
>
> Javascript's flow is single threaded, and a delay in execution (I/O
> starvation) will halt the entire script including timeouts and
> intervals. As such, timeouts and intervals are "kind of asynchronous",
> in that the script hypervisor is polling for these each "tick", and
> will direct program flow into them when encountered.
>
> Shawn is correct in that limiting execution to the modal window is
> an architecture / program structure issue. jqModal (when in "modal"
> mode) assigns a global event handler that examines the source of the
> event, and stops it from propogating (and calling any other attached
> event) if it occurs OUTSIDE the modal dialog. This mimick's modal
> behavior -- but will NOT halt the execution setTimeout/Interval and
> ajax handling. To halt these processes, you could examine the state of
> the modal dialog in the handling function, and return false if it is
> "open". E.g.
>
> -- handling function --
> if ($('#modalDialog').is(':visible')
> return false; // handle not!
>
> // handle ho!
> ...
> -- !handling function --
>
> Hope this helps,
>
> ~ Brice
>
> On Nov 14, 8:42 pm, Shawn Grover <[EMAIL PROTECTED]> wrote:
>
> > This is a coding approach issue, rather than a modal window issue. To
> > me at least.
>
> > When I needed behavior like this, I wrote my code in such a way that a
> > function was called that set up the environment and then opened the
> > modal window. Now that the modal window is open, I know that nothing
> > else should be receiving events, so there is no code to execute other
> > than for the modal stuff specifically. Now when the window is closed, I
> > call the appropriate function (cancel, save, etc) and continue
> > processing from there. In this way, my processing has "stopped" until
> > the Modal window triggers the next part of processing.
>
> > Of course, this is not the answer for all cases. But, working in an
> > asynchronous and event driven environment, this tends to work well enough.
>
> > To acheive what you are asking for would be possible if you were working
> > in a synchronous or procedural environment. But that doesn't describe a
> > web page per se....
>
> > My thoughts...
>
> > Shawn
>
> > Richard D. Worth wrote:
> > > What I mean to say is, a modal isn't about stopping flow of code. It's
> > > about restricting interaction to a certain set of elements, until the
> > > interaction is complete. So it allows interaction with elements in that
> > > modal (requiring code flow - remember javascript is single-threaded),
> > > preventing interaction with all others, until it's closed.
>
> > > If you're wanting to call a modal like a function and have it return a
> > > value (think confirmation dialog), it won't work to block like that. An
> > > alternative pattern is to provide a callback function that will resume
> > > execution after the modal is closed.
>
> > > - Richard
>
> > > On Fri, Nov 14, 2008 at 4:48 PM, Eric Martin <[EMAIL PROTECTED]
> > > <mailto:[EMAIL PROTECTED]>> wrote:
>
> > > I guess it depends on what you mean by "flow of code must STOP".
>
> > > On Nov 14, 12:11 pm, Wagner <[EMAIL PROTECTED]
> > > <mailto:[EMAIL PROTECTED]>> wrote:
> > > > Is it possible to make a window like jqModal, etc, etc, BUT WITH A
> > > > REAL MODAL way of work?
>
> > > > I mean.... the flow of code must STOP until the window be closed!
> > > Does
> > > > it exist?
