I (kind of) insist that it has too great an educational value not to be included in the Manual.
Oh yeah. Okay, next time.
What's it an example of, do you think?
Adapting primitives to be more useful?
Imho, it is an example of an input to a custom block, that is:
-
defined as Any_type
-
with default value being a "menu" (in contrast to being "options" (with lots of submenus, described on much of the page 47) )
- more precisely a menu of "sprites" (called "objects" in the printscreen below)
-
and because it is Any_type, a user is able to override the default value by dragging into the input slot a list (of x and y values which are than handled by the IF... ELSE... block) instead.
Imho, it could be inserted at the bottom of page 46, so that it would precede the lengthy description of "options (with lots of submenus)".
Oh, interesting. I hope I'm not about to change your mind about what a good example it is, but you have a slightly incorrect model of what's happening here, because the graphical presentation isn't quite right. That input isn't an Any type with a sprite menu as its default value. It's an input of Menu type, and really we should unclick all the radio buttons in the top half when you make it a menu.
You can always drag an expression over an input slot, the way you can drag a list over the menu slot in this block. We don't syntactically type-check inputs; Snap! is a dynamically typed language (also called "weakly typed"), which means that it's not until you call a primitive that an input may be rejected as not being in the domain of the function. If the expression you drag in is a primitive, such as a LIST block, then we could type-check it if we wanted, but if what you drag in is a custom block, we have no idea what its range is. (Dan Garcia wants us to allow an optional result type-declaration when you make a custom block, so we could do syntactic type checks.)
There are only a few situations in which we treat certain input expressions specially as you're writing code. If you drag an orange variable block into the first input slot of CALL or RUN, or any other Procedure-type input slot, we remove the gray ring around that input. If you drag an expression over a C-shaped slot of a custom block, the slot changes from C-shaped to inline. (One of my minor annoyances about Snap! is that primitives with C-shaped slots don't behave the same way.) But these aren't type checks; we don't know what the type of the value of the variable in the CALL/RUN case is until you actually run your code, but we know it's a variable (which isn't a data type).
So, you could drag a list-valued expression over any input slot, Menu-type or otherwise. You declare input types only as a form of documentation for the user of your block, except for Procedure types which have the special behavior about variables erasing the ring.
I thought you had to right-click the dark background of the type dialog to get the menu menu, but apparently you can do it anywhere in the dialog. Who knew?
Can you explain what you mean by this, preferably on a screenshot with a few arrows added, please, since I have no idea what you are saying (I guess I'm saying "It's a 'stupid question time', kids!").
P.S.
Is this what are you saying - see pic below?
I can't remember seeing this written anywhere, yet; so - if it is not yet in the Manual - can you insert this sentence for example as shown below?
I guess the manual should explain this better, but re-reading what I said, it isn't quite true enough for a manual.
More true:
There isn't really a Menu type; I said that wrong. The problem is that we need a name other than "type" to mean "miscellaneous syntactic category" to describe special cases such as a variable in a Procedure-type input slot.
In order to have menu as the appearance (a name I just made up) of an input slot, the slot's Type has to be something compatible with text strings: Any, Text, or Number (the last of which is, for this purpose, a kind of text string restricted to digits). That's because text strings are all you can type into the Input Slot Options dialog box. (By definition, anything you can type, in any context, is a text string; your keyboard has text characters on it.)
And sure enough, if you right-click on the input type dialog and the selected type isn't a Text-compatible type, instead of this menu
you only get this one
I didn't know that until playing around with it just now! That's why it's not in the manual.
I don't really understand why you get even that little menu, because both "multi-line" and "code" really apply only to Text-compatible types too. I'm gonna have to ask Jens to clarify his intent for me.
One might think that if you choose menu>objects your input's Type would be Object, but that's not the case; your menu will still look like a text box, and the values in the menu are actually names of objects (i.e., text strings), not actual objects.
So I should have said "You declare input types inly as a form of documentation for the user of your block, except for Procedure types which have the special behavior about variables erasing the ring, or Text-compatible types which allow for pulldown menus, or non-Text-compatible types which don't have white boxes into which the user can type stuff."
Ok. Talking about the manual, which I am re-reading, again, you say: "... experienced Scratch users can skip to subsection B" somewhere in the beginning. Do you mean the subsection about "Nesting sprites" or some other subsection?
Yes. The subsections are labelled, aren't they?
do you mind giving me the JS code for all sprites but not the current one? (so I can use the JS feature in dropdown menus for a more exact version, and I will add mouse pointer and center manually.)
Don't look at me! I'd have to dig through the code looking for it, same as you.
This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.