Why in some primitive blocks we can't place blocks inside of text(1) slots?
Go to (position) is a special case. Inputting a list causes the caller to go to the position specified by the list.
For example: Go to [0, 0] causes the caller to go to x 0 y0.
Some blocks have menus that are meant to mean specific things, while others, you can input reporters. An example is, the set variable block. You can't stick a block in the name input, because what if the variable doesn't exist? (It'll just error, so...). The go to [random position] block is an example of why you can input blocks into most dropdown inputs. You can put a list inside the input, which the sprite will go to if it's a valid coordinate.
Oh, and you can actually put custom text in the dropdowns that you can't put blocks in, just call / run them with inputs, and set the dropdown to an empty string.
(bh can explain this whole thing better. I know, because something like this has been asked before).
:~) Nah, you did fine. I just would have added a picture or two:
... but in cases like this, with a fixed set of options, giving the block an input it doesn't understand isn't going to give a useful result.
(Being able to do that, by the way, substituting an input value into the menu input, is why every Snap! menu has an empty value as its first choice. Recall that substitution of inputs only substitutes for empty slots.)
But generally speaking, inputs that have menus but can make sense of inputs other than the ones provided have the menu pulldown thing in a white input slot, whereas menu inputs that can't make sense of an arbitrary input have block-colored input slots:
The GO TO block that started this discussion is a little special because you can't directly type a list into an input slot anyway; you have to use the LIST block to make the input. So it wouldn't help for the slot to be white; it'd just confuse people.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.