# Incompatibility between Dynamic’s second argument and Wolfram Demonstrations

A central feature of the Wolfram Demonstrations is the use of multiple instances of the Manipulate output, placed into the Thumbnail and Snapshots sections – for instance here, that are used to illustrate different control settings and corresponding displays. However that seems to preclude the use of Dynamic’s second argument for various control variables to either change the expression displayed, or to limit or constrain the choices available for other controls. To illustrate, the following shows the bare bones code for a Manipulate and two separate instances of its output with 3 three controls adjusted to give different displays:

Manipulate[
Plot[{Cos[frq$a x], Sin[frq$b x + plt$ph]}, {x, 0, 10}, ImageSize -> {250, 170}], Row[{Style[Text["Multiplier 1: "], 12], Slider[Dynamic[frq$a], {1, 10}]}],
Control[{{frq$b, 2, "Multiplier 2"}, 1, 4}], DynamicModule[{ctrl, b}, Row[{Style[Text["Phase: "], 12], Slider[Dynamic[ b, (b = #; ext$var$1 = b + 3; plt$ph = b + 3) &], {0, 10}]}]],
LocalizeVariables -> True,
Initialization :> (plt$ph = 3; frq$a = 5)]


In the display, changing either of the Multiplier 1 controls causes the physical position of the other one to change in lock-step, with both displays changing likewise. But changing either of the Multiplier 2 controls changes only that physical control setting (frq_b) along with the corresponding frequency (the red trace, the higher frequency sine wave in the right-most display). And, finally, in an attempt to get the unlinked features of the Multiplier 2 controls while keeping the necessary features of Dynamic associated with the Multiplier 1 control, I created a DynamicModule that incorporates another Slider control (plt_ph). However, while those two controls themselves are not physically linked – as indicated by their two different positions – when either one is changed the variable plt_ph is changed in both and both displays update accordingly.

So my question, though a bit of a wan hope, is whether there’s some way of obtaining that combination of features, i.e., the non-linked capability along with the ability to use Dynamic’s second argument to implement various other functions. Somewhat in passing, it seems suprising that the control Multiplier 2 – implemented as Control[{{frq_b, 2, "Multiplier 2"}, 1,4}] – creates a variable that seems to have separate instances, and values, between the two outputs. Consequently, it seems possible that something similar could implemented with the other control variable, plt_ph.

• I don't use Manipulate but evaluating your code I notice that the variables are not actually being localised. If you examine the underlying show expression you'll see that the two variables that are initialised do not make it into the list of local dynamic module variables. As a non Manipulate user I do not intend to try and figure why the LocalVariables option doesn;t appear to be doing what you expect. Have you considered just using DynamicModule and avoid the Manipulate headaches? Mar 6, 2016 at 7:21
• @Steersman, why do you need all these complicated stuff, if just {{frq$a, 5, "Multiplier1"}, 1, 10}, Control[{{frq$b, 2, "Multiplier 2"}, 1, 4}], {{plt$ph, 3, "Phase"}, 1, 10}] is enough? Mar 6, 2016 at 7:22 • @MikeHoneychurch : While you kind of have to download one of the examples from the Demonstrations Project area - link in the OP - to see the specific format they expect, they do stipulate that you have to use the Manipulate function, and without too many fancy elements. And The Author Guidelines page emphasizes and elaborates on that requirement. Mar 6, 2016 at 7:47 • I'm confused by "either of the Multiplier 1 controls", because there is only one. Nothing else changes in lock-step when I move it. I can't tell if you're describing the provided example as it is or how you would like it to be. I don't see a point to having two controls in lock-step with each other, so I feel like I'm misunderstanding something. Here's a demonstration with a custom control that uses the second argument of Dynamic: demonstrations.wolfram.com/TheGeometryOfLagrangeMultipliers Mar 6, 2016 at 13:15 • Ah, I didn't realize they were to be linked between the Manipulates. (I don't think that's allowed on the Demonstrations site. The "Snapshots" on the website are just rasterized images, not functioning copies of the demonstration.) Mar 6, 2016 at 19:54 ## 2 Answers I'm still not sure what the desired functionality is in the working example. Here's my guess. If it's off, I apologize. Manipulate[ Plot[{Cos[frq$a x], Sin[frq$b x + plt$ph]}, {x, 0, 10}, ImageSize -> {250, 170}],

{{frq$a, 5, Style[Text["Multiplier 1: "], 12]}, 1, 10}, (*$*)
{{frq$b, 2, "Multiplier 2"}, 1, 4}, (*$*)
{{b, 0, Style[Text["Phase: "], 12]}, 0, 10,                             (*$*) Manipulator[Dynamic[b, (b = #; ext$var$1 = b + 3; plt$ph = b + 3) &], {0, 10}] &},
{{plt$ph, 3}, ControlType -> None}]  I'm not sure what ext$var$1 is for. I took the prefix ext to indicate it should be a global (i.e. external) variable. One can watch it change like this: Dynamic@ext$var$1  But there's no point to such variables in Demonstrations, since they run in a private context, not "Global", I think. • Thanks for the example which is more or less exactly what I was looking for - I'll create another answer to elaborate. But I copied your code to a Demonstration template, where it worked as advertised, and then uploaded it 2 my "Authoring Area" where it was accepted as meeting some minimal set of requirements. Won't do a submit for publication but that is one hurdle surmounted. BTW, I noticed if I put {{frq_a ...} in a Control wrapper the colour of frq$a changes from green to black indicating "variables made special by ..." Any idea what that means? And you're right - ext$var for tests Mar 7, 2016 at 3:15 • @Steersman The coloring of frg$a is done by the front end recognizing certain syntax patterns. When it works right, the color tells you something about what kind of variable the symbol is (global, local Module, function argument, etc.). Unfortunately, the front end is not set up to recognize Control[...]. I don't know why. It's unfortunate, but it doesn't mean anything. I might say it's a bug, but it's been that way for a while now. Mar 7, 2016 at 3:26

The following provides some clarification and elaboration on what “the desired functionality” is intended to be. As the target application uses 3 or 4 sets of TogglerBars, Togglers, and Checkboxes – not all of whose combinations are valid or which make sense – the Dynamic second argument seems an ideal way of implementing the appropriate restrictions. In the following simplified example, the Dynamic function for the TogglerBar in particular ensures that valid combinations are selected, and that various other control variables are set prior to the Plot functions being displayed:

Manipulate[
If[(MemberQ[go$optns, go$frq$a]) && (MemberQ[go$optns, go$frq$b]),
Plot[{Cos[frq$a3 x + plt$ph3], Sin[frq$b3 x + plt$ph3]}, {x, 0, 10},
ImageSize -> {300, 170}],
If[MemberQ[go$optns, go$frq$a], Plot[Cos[frq$a3 x + plt$ph3], {x, 0, 10}, ImageSize -> {300, 170}], Plot[Sin[frq$b3 x + plt$ph3], {x, 0, 10}, ImageSize -> {300, 170}]]], Control[{{sel$enbl$2, True, Style[Text["Selection Enable:"], 12]}, Checkbox[ Dynamic[sel$enbl$2, (sel$enbl$2 = #; optn$enbl = sel$enbl$2) &], {False, True}] &}],
Control[{{go$optns, {go$frq$b}, Style[Text["Graph Options:"], 12]}, 1, 5, TogglerBar[ Dynamic[go$optns, (If[(Length[#] != 0) && (MemberQ[#, go$frq$a] ||
MemberQ[#, go$frq$b]), go$optns = #]; If[! MemberQ[go$optns, go$ph], (plt$ph3 = 0; ctl$ph = 0; ph$enbl = False), ph$enbl = True]) &], {go$frq$a -> "Frequency A", go$frq$b -> "Frequency B", go$ph -> "Frequency & Phase"},
Enabled -> Dynamic[optn$enbl]] &}], Control[{{frq$a3, 5, Style[Text["Frequency A:"], 12]}, 1, 10}],
{{frq$b3, 2, Style[Text["Frequency B:"], 12]}, 1, 4}, Control[{{ctl$ph, 0, Style[Text["Phase:"], 12]}, 0, 10,
Manipulator[
Dynamic[ctl$ph, (ctl$ph = #; ext$ph$1a = ctl$ph + 3; plt$ph3 = ctl$ph + 3) &], {0, 10}, Enabled -> Dynamic[ph$enbl]] &}],
{{plt$ph3, 3}, ControlType -> None}, {{optn$enbl, True},
ControlType -> None},
{{ph\$enbl, False}, ControlType -> None}]


The following image shows two separate instances of the Manipulate output cell with different sets of control settings. Which is exactly what is required for the Demonstrations project:

It was particularly interesting to note the use of {{ph_enbl, False}, ControlType -> None} which I assume creates variables local to each instance of the Output cell of the Manipulate. Which is apparently what the use of Control[…] does, as does its more rudimentary form, e.g., {{frq_b3, 2, Style[Text["Frequency B:"], 12]}, 1, 4}`.

• draw attantion to the color of plots as well. Mar 7, 2016 at 6:37