a = 1;
Button["Print", a++]
Button["Print", Dynamic[a++]]
Button["Print", Dynamic[a++];]
Button["Print", {Dynamic[a++]}]
Dynamic @ a
The second Button
is not supposed to change the value of a
but it does.
Have I missed something or is it a bug?
Why it is not supposed to?
Button[label,action]
[...] evaluates action whenever it is clicked.
Evaluation is supposed to leave Dynamic
intakt and if it is part of returned result MakeBoxes
will create DynamicBox
which is supposed to be handled by FrontEnd
which should send contents to evaluation when needed.
Yet the Button
isn't creating any visible result when clicked.
While Button["Print", Dynamic[a++]]
isn't useful in general, the leak is the leak.
A support case with the identification [CASE:3609709] was created
[...] I have filed an incident report with the information you provided.
[...] I have also filed a second incident report for the documentation example [...]
Answer
To understand this, look at the typesetting:
In[1]:= ToBoxes[Button["Print", Dynamic[a++]]] // InputForm
Out[1]//InputForm=
ButtonBox["\"Print\"", ButtonFunction :> Dynamic[a++], Appearance -> Automatic,
Evaluator -> Automatic, Method -> "Preemptive"]
Front end options, which includes all box options, can take Dynamic
heads. That basically means that the FE will compute the value of the Dynamic
and use it for the option. And that it will be updated whenever a Dynamic
dependency updates.
Because Button
is passing its second argument unmolested to the right-hand side of ButtonFunction
, it looks like a Dynamic
rhs which needs to be computed by the FE. And that computation increments a++.
At first, I was surprised that it didn't increment by virtue of simply being displayed on the screen. I.e., I might have expected a
to be 2 even before you pressed the button. As it turns out, it doesn't because it's in a class of options which are treated as always held, until they're actually used. Other such options include the Initialization
, Deinitialization
, and TrackedSymbols
options of various boxes. And too many more to list, but only a small number of the overall number of options.
So, is it a bug? Maybe. These "always-held" options certainly don't gain any benefit from Dynamic
handling. However, if we added special handling for them, then we'd have to list all of the options and document why they're excluded from standard Dynamic
handling, which I think would be burdensome for everyone. I think I would lean towards calling it not a bug.
I think the better thing in this case would be to properly document that the second argument of Button
is passed to ButtonBoxOptions->ButtonFunction
.
Comments
Post a Comment