4
$\begingroup$

I saw a Dynamic snippet in this answer, which wrote

DynamicModule[{font}, 
 Row[{PopupMenu[Dynamic[font], 
    FE`Evaluate[FEPrivate`GetPopupList["MenuListFonts"]]], Spacer[20],
    Style["The quick brown fox", 20, FontFamily -> font]}]]

Things confusing me most are that I thought the Style[ ... ] part should be wrapped in a Dynamic[ ... ], but to my surprise it doesn't need one in the above code for (at least looks like) working correctly!

So I did some experiments in Mathematica 9:

Working:

DynamicModule[{col},
 Row[{
   PopupMenu[Dynamic[col], {Red -> 1, Blue -> 2}],
   Style["text", FontColor -> col, 20]
   }]
 ]

DynamicModule[{col},
 Row[{
   PopupMenu[
    Dynamic[col], {RGBColor[1, 0, 0] -> 1, RGBColor[0, 0, 1] -> 2}],
   "\!\(\*StyleBox[\"\\\"text\\\"\", Rule[FontColor, $CellContext`col$$]]\)"
   }]
 ]

Not Working:

DynamicModule[{col},
 Row[{
   PopupMenu[Dynamic[col], {Red -> 1, Blue -> 2}],
   col
   }]
 ]

DynamicModule[{col},
 Row[{
   PopupMenu[Dynamic[col], {Red -> 1, Blue -> 2}],
   Style["text", col, 20]
   }]
 ]

DynamicModule[{col},
 Row[{
   PopupMenu[
    Dynamic[col], {RGBColor[1, 0, 0] -> 1, RGBColor[0, 0, 1] -> 2}],
   "\!\(\*StyleBox[\"\\\"text\\\"\", $CellContext`col$$]\)"
   }]
 ]

Questions:

  • Why is this Dynamic-wrapping-free behavior of Style? My personal suspicion is, a proper form (i.e. with explicit option names) of Style[ ... ] is handled by the FrontEnd. Please correct me if I'm wrong.

  • Should I take advantage of this feature(?), or should I generally avoid it?

$\endgroup$
2
  • $\begingroup$ Even stranger: DynamicModule[{col}, Row[{PopupMenu[Dynamic[col], {Red->1, Blue->2}], Plot[x^2, {x, -2, 2}, BaseStyle->{FontColor->col}]}]] -- the color change is off by one, if you toggle back and forth. $\endgroup$
    – Michael E2
    Commented May 21, 2013 at 19:51
  • $\begingroup$ @MichaelE2 Interesting... Need to leave for an hour for urgency, will investigating after. Thank you for your instance! $\endgroup$
    – Silvia
    Commented May 21, 2013 at 19:57

1 Answer 1

8
$\begingroup$

You definitely should not rely on this behavior.

There is one and only one proper way to get dynamic behavior for the rhs of a front end option, and that is to wrap Dynamic around the entirety of the option. The only exceptions to this rule at present are certain options which will assume the Dynamic if one doesn't exist, such as CellDynamicExpression and friends. There might also be some options which correctly allow Dynamic in a subexpression that I'm not thinking of.

So why does it work? The FE has to put something in for the value if it gets a poorly formed or erroneous expression for an option. The handling of such cases is sometimes a little sloppy and not entirely consistent. There was a thought in v6 on the part of some developers, for example, that not wrapping a Dynamic would cause a one-time evaluation that might go to the kernel. This was never documented, and the implementation was sloppy; I wouldn't be surprised if it's that feature which led to the behavior you're seeing here.

The code you quoted was written by me. The lack of a Dynamic was a simple oversight on my part, enhanced by the fact that it actually worked. You shouldn't read anything into the missing Dynamic as some super-secret feature or highly advanced programming technique which should be emulated. I make mistakes, too. Lots of them.

I've edited the answer you linked to in the hope of reducing future confusion.

$\endgroup$
1
  • $\begingroup$ Thank you very much for your explanation! You have fulfilled my curiosity! $\endgroup$
    – Silvia
    Commented May 21, 2013 at 21:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.