# Is there a way to tell if the input to a custom block is a specific block?

For example, instead of the following script checking if the input IS a random number between 1 and 10, could it check whether the input WAS the pick random block, and the inputs that the block had been set to?

what's your input number () of [] script?

It's a block to get the first and second inputs from the [scratchblocks]pick random (1) to(10)[/scratchblocks] block.

i.e. [scratchblocks] (1) and (10)[/scratchblocks]

I know what it does. I'm just wondering what the script is that you used to code the block.

No, the problem is, I don't have the script.

Maybe there is some js code that someone could help me?

EDIT: Whoopsie, didn't mean to prefix the 'please' with an 'O'
It looks quite comical actually - O please help me, loyal knight - I think I'll keep it.

if you look at @pumpkinhead's Script builder library, there's a block that does what you want it to do.

My library doesn't have the ability to see if this block is a specific block. Though if you look at the Stage in that project, there is a JavaScript block that allows you to get the block spec of a block (which is a string). I hadn't made that into an actual block because I'm not sure if that block would be useful.

Also, you could instead make a separate make random color block.

Yeah, exactly.

This request (made twice now?) is the sort of thing that always results in Jens yelling at me (because he knows we're not supposed to yell at kids, so I serve as the whipping boy). Namely, a solution in search of a problem. You (not you singular, @silver_star) think, "what would be a cool feature?" instead of thinking "hey, I'm having trouble writing this project, what I need is a way to do this."

So, what the make an A color block at the beginning of this thread does is that one time out of ten it picks a random color instead of the one the user provided. The straightforward way to do that is

There was a bug, which I've fixed, in the original code: the variable color that it sets is local to the block, so the result is not visible to the rest of the program. Here I've used input as the name of that local variable, so color can be a global one.

But what you hoped your block would do is such a strange thing to want to do! You're thinking that the user will either give a specific color as input or else use a pick random block. And in the latter case you want to provide a random value.

But in that latter case, your input already is a random number in exactly the range you want to use! So there's no need to check for that case.

So, what I suggest is, @silver_star, go make a project that does something that interests you. If, in the course of making the project, you find that you don't know how to do something, then come here and ask for help. But don't look for ways to do things that don't actually solve a problem you're having.

(I'm not mad at you, or yelling at you. Just, the forum is to support you in writing Snap! programs; it's not an end in itself.)

Quite a strange concept, with the side effect of join and lambda, but working...

I think that works because the join block will convert the lambda to a string, and the Snap! programmers made the string representation of the lambda return its block spec and other information. This is most likely not intentional.

Semi-intentional.

Back at the dawn of time, in Scratch, where nothing is first class except text and numbers, they made text representations for everything -- not complete representations from which you could rebuild the original, just something that sorta looked like it had something to do with it.

Snap! continued that idea. In particular, the JOIN block takes anything as input, and it produces a text string from whatever you give it. So, yeah, that's deliberate.

But now that pretty much everything is first class, it can be argued that JOIN should return a "multimedia string" rather than a text string. More generally, every part of Snap! that knows about text should know about every kind of value we can make. Wouldn't you like to be able to put a script in a comment? Especially the comment on the hat block that becomes the help for your custom block! So, probably someday, this behavior will change -- but by then I'll have built a general script-to-tree function based on your work.

I understand how the example I gave wasn't the best.