Re: Problems with ChoiceDialog inside a Dynamic: Bug or not (well) documented limitation?
- To: mathgroup at smc.vnet.net
- Subject: [mg107811] [mg107811] Re: [mg107725] Problems with ChoiceDialog inside a Dynamic: Bug or not (well) documented limitation?
- From: John Fultz <jfultz at wolfram.com>
- Date: Sat, 27 Feb 2010 03:12:59 -0500 (EST)
- Reply-to: jfultz at wolfram.com
Synchronous Dynamics (which is what you get by default) are stop-the-world sorts
of evaluations. When they're running, any ongoing kernel computation is
completely halted, and the Dynamic evaluation is completely uninterruptible.
Even another Dynamic evaluation cannot interrupt it. Likewise, the front end is
locked into a mode where it can only respond to a very limited number of events
while it awaits the resolution of the Dynamic.
For this reason, all synchronous Dynamics are evaluated, by default, with a
TimeConstrained wrapper using a time derived from the EvaluationDynamicTimeout
option in the kernel. This option can be tailored on a per-Dynamic basis if you
like using the Style[] function to set the option. The goal is that absolutely
no Dynamic should be allowed to lock up the front end and kernel in such away
that they appear unresponsive to users.
ChoiceDialog[], or any other function which awaits user input, causes the kernel
to wait for results, but doesn't stop the timer in TimeConstrained[] from
expiring.
Any Dynamic which you expect to take a long time should be using
SynchronousDynamic->False. This causes the Dynamic to be put into the same
queue as Shift+Enter evaluations, and it can take as long as you want. So it's
not evaluated urgently, but there will be no need for it to evaluate urgently,
either.
Incidentally, the same thing applies with Method->{"Queued"} (as opposed to
"Preemptive") in Button and ActionMenu.
Sincerely,
John Fultz
jfultz at wolfram.com
User Interface Group
Wolfram Research, Inc.
On Thu, 25 Feb 2010 01:49:43 -0500 (EST), Guido Tripaldi wrote:
> Hi Group,
> suppose you wanna to display an alert to the user before to continue the
> execution of your code when some conditions occur : probably you'll use
> ChoiceDialog[], the useful function that "puts up a standard choice
> dialog that displays expr together with OK and Cancel buttons, and
> returns True if OK is clicked, and False if Cancel is clicked.".
>
> But if you use this function inside some Dynamic[] object, it hangs the
> kernel. I've tried to find in the documentation some references to this
> bad combination without any luck, so I don't understand if this is a bug
> or there is something missing in the code.
>
> To better explain the problem here is a very basic example:
>
> (* just a silly example *)
> Grid[{
> {"Choose a dividend: ",
> PopupMenu[Dynamic[dividend], Table[i, {i, 0, 10}]]},
> {"Choose a divisor : ", PopupMenu[Dynamic[divisor], Table[i, {i, 0,
> 10}]]},
> {"Quotient: ", Dynamic[dividend / divisor]}
> }, Frame -> All]
> Dynamic[
> If[divisor == 0,
> ChoiceDialog["Uh-oh, you are going to do a division by zero! Please
> select a different divisor.", {"Ok"}];
> ]];
>
> Instead, if you use the MessageDialog[] function to show a message
> window, all works well, but of course the execution will continue without
> waiting for the user action (that is not what I want).
>
> Same situation if you try to use ChoiceDialog[] inside a TabView, or
> other kind of Views:
>
> (* another silly example *)
> TabView[{
> "Tab1" -> Button["Show ChoiceDialog", result = ChoiceDialog["This hangs..
> :-(."];],
> "Tab2" -> Button["Show MessageDialog", MessageDialog["This works!"];]
> }]
>
>
> Any suggestion?
> thanks!
> G
>
> ps
> M7.0.1.0 on Mac Snow 10.6.2
>
> ---
> Guido Tripaldi