Take the 2-minute tour ×
Mathematica Stack Exchange is a question and answer site for users of Mathematica. It's 100% free, no registration required.

Inserting a Dynamic object in a boxform expression messes up syntax colouring. See the following example. where the variable local is dynamically replaced at the box level, and the syntax highlighter cannot keep up with it.

on = True;
Row@{
     Checkbox@Dynamic@on, Spacer@10,
     ExpressionCell[RawBoxes@RowBox@{"Block", "[", RowBox@{
      RowBox@{"{", "local", "}"}, ",",
      RowBox@{"{",

        (* autostyling applies fine *)
        "local", ",",
        ToBoxes@ToExpression["local", StandardForm, HoldForm], ",",
        ToBoxes@Dynamic@ToExpression["local", StandardForm, HoldForm], ",",
        ToBoxes@Dynamic@If[on, ToExpression["local", StandardForm, HoldForm],
            ToExpression["local", StandardForm, HoldForm]], ",",

        (* autostyling applies only for initial display *)
        ToBoxes@Dynamic@If[on, ToExpression["local", StandardForm, HoldForm],
            ToExpression["global", StandardForm, HoldForm]], ",",

        (* autostyling does not apply *)
        ToBoxes@"local", ",",
        ToBoxes@Dynamic@"local", ",",
        ToBoxes@Dynamic@If[on, "local", "global"],
        "}"}
      }, "]"}, "Input", ShowAutoStyles -> True, LanguageCategory -> "Mathematica"]}

When the checkbox is clicked, it switches between:

Mathematica graphics Mathematica graphics Mathematica graphics

and so on... Note, that the 5th local in the body of Block stays blue. How to overcome this?

share|improve this question
    
I may be mistaken, I don't think the If statement in your last example can be converted to boxes and still be interpreted as code. I also might not be understanding the exact goal. Using HoldForm@undefined instead of "undefined" yields a blue symbol in the output. But I suspect that won't help your actual case. –  Michael E2 Mar 16 at 17:03
    
@MichaelE2 You are right, I made a mistake with the stringified variable name, let me think it over again. –  István Zachar Mar 16 at 17:06
    
Deleting until problem is better understood. –  István Zachar Mar 16 at 18:31
    
@MichaelE2 I have successfully narrowed down my original problem to this minimal working example - question has been rewritten entirely (though title remained as it still applies). I have no idea how to solve this. –  István Zachar Apr 3 at 9:33
    
I think you'll have to force the FrontEnd re-render the ExpressionCell after each update of the on. Usually this can be done by placing the cursor in the cell or changing the options of the cell. However, inline cell seems a little tricky... Maybe for this case, you'll have re-generate the cell everytime on changed... –  Silvia Aug 16 at 20:54

2 Answers 2

The last three locals are actually String, i.e. "\"local\"" at the box level. The fourth from the end, however, should be due to lacking of syntax highlight at the FrontEnd.

For this problem, I guess you'll have to force the FrontEnd re-render the ExpressionCell after each update of the on. Usually this can be done by changing an option of the cell (like deleting CellChangeTimes etc.). However, inline-cell seems a little tricky, I found that placing a cursor in it will do the work. So here is one possible workaround (works in my 10 and 9.0.1, but in 9.0.1 it sometimes "flickers").

The main idea is to run a scheduled task to track the update of on, then trigger an action simulating cursor clicking inside the inlined ExpressionCell, which I believe will force the FrontEnd to re-render it.

The scheduled task code:

oldvalue = on;
RunScheduledTask[
    If[
        on =!= oldvalue,
        Module[{nb = SelectedNotebook[]},
               SelectionMove[nb, Before, CellContents      ];
               SelectionMove[nb, Next  , Character   , 9   ];
               SelectionMove[nb, Next  , Character   , 1000]
              ]
        ];
    oldvalue = on,
    0.01]

While the task is running, manually place cursor behind or in the Checkbox's cell, then click the Checkbox.

force refresh FrontEnd

share|improve this answer

Pardon me if this is unjustifiably curt but I don't see how this problem is different from many others that result from placing Dynamic too deep within an expression. Move the Dynamic to the outside and the element in question updates just fine:

on = True;
Row@{Checkbox@Dynamic@on, Spacer@10, 
  ExpressionCell[
   Dynamic@RawBoxes@
     RowBox@{"Block", "[", 
       RowBox@{RowBox@{"{", "local", "}"}, ",", 
         RowBox@{"{",(*autostyling applies only for initial display*)
           ToBoxes@If[on, ToExpression["local", StandardForm, HoldForm], 
             ToExpression["global", StandardForm, HoldForm]], "}"}}, "]"}, "Input", 
   ShowAutoStyles -> True, LanguageCategory -> "Mathematica"]}
share|improve this answer
    
+1 for making it work. But I still think there is a bug (or at least inconsistency). For example the following code: openflag=True;Checkbox[Dynamic[openflag]](*need a newline*) RowBox[{"Module","[",RowBox[{RowBox[{"{","a","}"}],",",GridBox[{{FrameBox["\"col‌​umnhead\""]},{DynamicBox[If[openflag,RowBox[{"a","=","1",";"}],""]]}}]}],"]"}]//C‌​ell[BoxData[#],"Input"]&//CellPrint, it behaves good in 10.0, but in 9.0.1 I'll need to "refresh" the cell (e.g. toggle "show cell expression" then toggle back) to make the a in the Column being correctly highlighted. –  Silvia Aug 17 at 6:11

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

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