MathGroup Archive 2011

[Date Index] [Thread Index] [Author Index]

Search the Archive

Re: What is the point of having Initializations in DynamicModule and Manipulate?

  • To: mathgroup at
  • Subject: [mg123031] Re: What is the point of having Initializations in DynamicModule and Manipulate?
  • From: John Fultz <jfultz at>
  • Date: Mon, 21 Nov 2011 04:26:55 -0500 (EST)
  • Delivered-to:
  • Reply-to: jfultz at

This is no accident.  It's very carefully thought out design.

Question...what do I do if I want thing A to evaluate before thing B?  Why, of 
course, use any number of Mathematica paradigms for sequential evaluation. The 
semicolon, representing CompoundExpression, for example.  No need to invent
anything here.

Further question...what if I want thing A to evaluate before thing B, but thing 
B is part of a dynamic interface.  This is the interesting question.  There are 
absolutely no guarantees about the order in which two discrete Dynamics will
evaluate, so I can't set up multiple Dynamics in a row to evaluate in sequence.  
I could nest Dynamics (outer ones always evaluate before inner ones), but then I 
may have to play some tricky games with Refresh to prevent code from evaluating 
which should only ever evaluate once.

So, what I want is an Initialization option.  Guaranteed to only ever evaluate 
once, and always evaluates before its Dynamic contents.  So, we added the 
Initialization option to Dynamic.

But we later realized that a similar problem comes up with DynamicModule. It's 
quite reasonable to want to "prime" a DynamicModule when the FE 
instantiates/displays it, which might involve setting initial values of the
DynamicModule variables, but it might also involve a bunch of other related code 
evaluation (common example, loading a package).  So, we added the same concept 
of an Initialization option of DynamicModule as to Dynamic.  And it works in
exactly the same does not evaluate until the FE is ready to display the 
DynamicModule, and then it queues to the Initialization option to happen first, 
and once only.

So, what about the issue of code inside a DynamicModule which is not wrapped in 
Dynamic?  Well, it's very important to understand that this code will never,
never, ever evaluate again after the Shift+Enter evaluation.  It does not 
evaluate when you load the notebook in a new session, for example.  So, any code 
inside of a DynamicModule, but not wrapped inside of a Dynamic, is UTTERLY 
USELESS, except insofar as it has side effects on setting DynamicModule 
variables which might be remembered in future sessions.  Any code which does
anything else is going to not be remembered in future sessions, and therefore 
risks creating interfaces which are busted in ways which aren't obvious unless 
you're testing for this sort of thing.

Furthermore, it introduces a weird evaluation order problem because you're 
mixing code evaluated at Shift+Enter time with code evaluated when the 
DynamicModule is actually displayed onscreen.  It's more bizarre than I've mentioned before, the result of evaluating:


does *not* set a because the contents of the Dynamic never evaluate because the 
contents were never displayed onscreen.  DynamicModule inherently wants to be, 
by design, a Dynamic-like construct...i.e., it does what it does when displayed 
onscreen, and in tandem with dependent Dynamics or DynamicModules.  But unlike 
Dynamic, DynamicModule does actually evaluate its contents at Shift+Enter time, 
to allow for the convenience of introducing non-trivial code for setting the

Now, let's suppose that you wanted the Initialization option to evaluate before 
that code.  What you would get is something even more bizarre and confusing.
You would have to do one of two things...

Option 1: Evaluate the Initialization option during Shift+Enter evaluation *and* 
when the FE instantiates/displays the DynamicModule.  Which means that you get a 
double-evaluation affecting the same DynamicModule variables.  I hope I don't 
have to say why double-evaluations are bad in the general case.

Option 2: The Initialization option would have to work differently for 
DynamicModules depending upon how and when the results were created.  I.e., it 
would fire during Shift+Enter evaluations sometimes, and during FE 
instantiation/display sometimes.  Which would also make the results much more 
difficult to understand, and I'm frankly not even sure how I would handle some 
of the corner cases to read the user's intent (what should a DynamicModule in an 
ExpressionCell do, for example?).

DynamicModule lives firmly in the world of FE-instantiated evaluation, despite 
the ability to initialize its variables at Shift+Enter time.  The correct design 
is for all of its options to similarly live in the world of FE-instantiated


John Fultz
jfultz at
User Interface Group
Wolfram Research, Inc.

On Sat, 19 Nov 2011 06:46:53 -0500 (EST), Armand Tamzarian wrote:
> I'd be interested in feedback from other users about the way in which
> Initializations works within DynamicModule (and Manipulate?). It is
> fair to say that I expected an initialization to occur "initially."
> That is to say I expected Initialization content to be evaluated prior
> to the body of the DynamicModule. I have exchanged emails with tech
> support about this. Attached is an example sent to me by tech support.
> ClearAll[plot, g];
> (* and in a separate cell *)
> DynamicModule[{c}, {plot, Slider[Dynamic[c]], g[Dynamic@c]},
> Initialization :> (g[x_] : Cos[x]; plot = Plot[g[x], {x, 1, 10}]),
> UntrackedVariables -> {g}]
> It is important for this example to keep the ClearAll line in a
> separate cell so that the global variables are only cleared once. On
> my system (OS X 10.6.8, Mathematica 8.0.4) the output is a list
> {plot, "slider", g[0.]}
> where "slider" is the actual rendered slider but plot is the word
> (unset variable) plot. In other words Global`plot has no value at the
> time the body of the DynamicModule is evaluated. Ditto Global`g.
> If you evaluated the cell (the second cell with the DynamicModule) a
> second time a plot graphic appears in the list and g[0.] becomes
> Cos[0.]. This is not surprising because Global`plot and Global`g now
> have a value.
> Wolfram have indicated that this is working as designed -- which is
> presumably why this example was sent to me of how this should work. If
> that is the case it seems poorly designed because (and it is here I
> would like feedback) users would expect initializations to be
> evaluated prior to the body of the DynamicModule -- otherwise what is
> the point?
> I'd appreciate the thoughts of other users about this.
> Additionally I have been told by Wolfram that wrapping Dynamic around
> the variable(s) that are not being evaluated will trigger the
> evaluation. But why would a user want to make plot or g Dynamic? It
> seems to me that the entire purpose of having an Initialization is to
> evaluate this "one off" variable/functions.
> thanks
> Mike

  • Prev by Date: Re: What is the point of having Initializations in DynamicModule and Manipulate?
  • Next by Date: Re: What is the point of having Initializations in
  • Previous by thread: Re: What is the point of having Initializations in DynamicModule and Manipulate?
  • Next by thread: Re: What is the point of having Initializations in DynamicModule and Manipulate?