5
$\begingroup$

A minimal example:

Graphics@Button[Disk[]]

will yield error message

Button is not a Graphics primitive or directive.

But if you drop Graphics@ part in the code above, generating a button:

enter image description here

Then you edit the output, simply apprending Graphics@ to it. And viola!

enter image description here

I have no idea why this aproach will work but the code won't.

So is this the correct behavior? Can we call this a (tiny) bug?

By the way, the error message is actually very misleading. A button that really does something (anything) will work perfectly well in Graphics. For example:

Graphics@Button[Disk[], bla]

will work.

$\endgroup$
0

1 Answer 1

1
$\begingroup$

On the Documentation pages both for Graphics and Button only the two-argument form of Button is mentioned as a wrapper allowed inside of Graphics. So I would not say that the behavior you describe contradicts the Documentation.

From the other side, for what purpose may you need a knowingly inoperative Button inside of Graphics? This approach looks like a wrong idea on its own, so I would not complain that it produces an error message. Button without the second argument is just a useless wrapper and the error message correctly warns that you are doing something wrong.

You have already provided an easy workaround - simple addition of the second argument of Button (even Null) "fixes" this: Graphics@Button[Disk[], ] does not produce the error message.

So there is nothing that can be called even a minor bug.

Why then your workaround through editing the output by prepending Graphics@ to it works? Let us see what the output Cell actually contains by appending //InputForm and evaluating inside of a Notebook:

screenshot

You see that the Button in the output Cell actually contains four arguments (but it is still the one-argument form of Button with options appended)! So the explanation is simple: Mathematica simply checks if Button contains only one argument and complains in this case. It seems to be the intended behavior but poorly implemented: more general case of one-argument Button with options was not considered by the developer. So it is not a bug, just careless without harmful consequences.

$\endgroup$
4
  • 1
    $\begingroup$ Yes, I agree with you. And I share many common arguments with you. What concerns me, and had baffled me, is the misleading message that this behavior may cause. As a newcomer who is not familiar with button in graphics, when I was trying to implement such a thing, I wasn't setting everything up in the first place, but firstly trying to see if an (empty) button will wrok well in graphics. By no means I would have known, in advance, that an empty button is considered "inappropriate" in this scenario. To make things worse, (continued)... $\endgroup$
    – Naitree
    Nov 29, 2014 at 18:02
  • $\begingroup$ an error message which states that a button will not work in graphics is certainly not helpful. I think similar "accident" may likely happen to other new users. And this can be really confusing for us. $\endgroup$
    – Naitree
    Nov 29, 2014 at 18:04
  • $\begingroup$ And my sincere thanks to you, for providing an thorough analysis on this (possibly trivial) question. :-) $\endgroup$
    – Naitree
    Nov 29, 2014 at 18:12
  • 1
    $\begingroup$ Thanks for the Accept. I agree that such a message is confusing for a new user if it face it without previous experience with Mathematica. Generally there are infinite number of such issues. And there are still at least hundreds of well-known issues which trouble newcomers for decades all the time: see this thread. Unfortunately the politics of the company still does not coincide well with expectations of the customers. $\endgroup$ Nov 29, 2014 at 18:16

Your Answer

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

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