# Understanding Dynamic, Refresh, and TrackedSymbols

I thought I had a pretty good handle on Dynamic, but some recent examples have made me suspect that I may have some misconceptions, and I am not finding good explanations of the places where I think I have such misconceptions. I would be grateful if anyone could either answer these questions or point me to resources that do so.

1) What is the difference between the following two formulations?

Dynamic[stuff,TrackedSymbols->{list}]
Dynamic[Refresh[stuff,TrackedSymbols->{list}]]


2) If you have nested Dynamic where you want to explicitly specify TrackedSymbols, do the inner tracked symbols need to be included in the outer list of tracked symbols? (I ask because when I didn't do that, the updating of the inner Dynamic seemed to get disabled.)

3) If the answer to 2 is "yes," then how do you specify symbols that you want to trigger an update of the inner Dynamic, but explicitly do not want to trigger the update of the outer Dynamic?

4) In the following structure, do symbols that are evaluated as part of fstart, f, and fend get automatically added to the Dynamic TrackedSymbols list?

Dynamic[stuff,{fstart,f,fend}]


5) Suppose I have a grid that is formatted to be part of a user interface of the following form. I seem to be able to make the entire thing Dynamic, but unable to make PART of it Dynamic. Is there any way around this?

Dynamic@Grid[Join[{{header stuff}},
{set of lines}&/@Range[something],
{another set of lines}&/@Range[something else],
{{footer stuff}}]] (*works*)

Dynamic[{set of lines}&/@Range[something]],
Dynamic[{another set of lines}&/@Range[something else]],
{{footer stuff}}]] (*doesn't work*)


1. In this case I'd not bother with Refresh but for the full answer see: What is the point of Refresh if Dynamic has an UpdateInterval option?

2. If you have nested Dynamic where you want to explicitly specify TrackedSymbols, do the inner tracked symbols need to be included in the outer list of tracked symbols?

Only if you want the outer dynamic to be updated when inner one's dependencies are changed.

(I ask because when I didn't do that, the updating of the inner Dynamic seemed to get disabled.)

Not true.

a = b = 1; Dynamic[{Echo[a], Dynamic[Echo[b]]}]


You will see 1 and 1 printed. Then run b++;, 2 associated with b will be printed.

3. The answer was NO. Moreover the fact that Dynamic don't bother with inner Dynamics is the very base of "nesting dynamics". A very useful concept for controlling updates.

See tutorial / AdvancedDynamicFunctionality / Nesting Dynamic, also a classic example with Manipulate and Dynamic inside as well as many other examples search nesting+dynamic.

4. I am curious how did you came up with this question because I never thought about that.

I think that would not be expected and fortunately it seems they are not added as 'triggers':

a = b = 1; foo = Echo[{#, b}] &;
Slider[Dynamic[a, {Automatic, foo}]]
Dynamic[a, {Automatic, foo}]


And then run b++;, neither of them was triggered.

5. Unfortunately, in general, no. Grid[Dynamic[...]] is typeset to GridBox[DynamicBox[...]] and as a rule GridBox needs an array as the first argument, otherwise it will complain.

I suggested FE team to introduce transparent boxes concept, that is to allow GridBox "see" past DynamicBox or PaneSelectorBox. The idea was to have something like Grid[{Dynamic[GridRow[{...}]], ...}]. I am not sure the importance of this request was recognized but it was not explicitly discarded :) otoh nothing happened yet.

As for workarounds, Dynamic @ Grid[... will often be the best way to go. Another one is to do

Grid[
{
Table[
With[{i=i},
Dynamic[{set of lines} @ something[[i]] ]
(*something is here in case it is supposed to trigger updates, idk*)
],
{i, Length[something]}
]
}
]


This way can be better if other static elements of the grid are big and not worth sending back and forth.

It could be worse when the list of Dynamics is long and watches the same symbols, then all those updates are done separately and it usually is slower than sending all in a one call.

At the end you need to be flexible, use both methods together with incorporating Column, etc etc.

• Thank you for the answers. On 1, the main difference I see is when setting a time-based refresh. Is there no difference if the refresh is not time-based? On 2, 3, and 4, I am having a very hard time reducing my problem to a minimal working example. Toy cases like your examples do indeed seem to work, yet my main system (which is extremely long and complicated) seems to show the behavior I described/asked about. Which of course probably means that I have misidentified what is causing my problem, and thus have not distilled the problem correctly. Thank you for your examples! And on 5, thank you. – Kevin Ausman Aug 27 at 23:02