# Suggested process for handling variable number of parameters for a custom block

Yes - that was the idea to have differenet variable name but I see if doesn't work

I'll have to see if adding in some invisible text will get around the issue...

It needs different title text, or a different number or placement of inputs:

Yes

This adds invisible text to start of block to sort it out - thanks for highlighting the issue

So corrected (corrected) version using invisible text option looks like this now

Try $- if you're fine with a gap: The spec of that is "$- something2 %m".

BTW why does the long input dialog appear when editing a "Title text"?

BTW: the concept of variant input assisted with reporter is borrowed from @wunder_wulfe project

Slightly crazy idea:
fill the dropdown with the block's variable names of the enclosing custom block (requires JS during edit).
Given custom block definition

dropdown is filled with

Input Slot Option:

function(){
let vars = this.parent?.parent?.parent?.variables?.vars;
if( !vars){ return {}};
return Object.fromEntries( Object.keys( vars).map( it =>[it,it]));
};


Test project

Getting cleverer and cleverer

I've been keeping away from using JS in menus since the change came and and I'm waiting for Snap! 7 to be released before revisiting the use of it.

Block variables, as opposed to script variables, have a pretty narrow utility. In particular, procedure inputs that are expected to be different in each call to the block should really be script variables.

I hate to say it, but this is a good use case for the Variables library, which Jens hates. You could dynamically create script variables for everything in the names list.

It'll be even better when I finally, if ever, get macros done, because what you really want is a block that takes the names list and the variadic input list as inputs, and creates script variables in its caller.

The Snap! 7 situation will be much like what it is now; you'll have to enable JS Functions to use JS in an input menu, except that libraries will be pre-approved.

Yes - but I've been caught before developing using dev so not going down that path again

Variable names in this scenario must be known upfront before running block, so they must be a part of some constant definition. Block variables are also much better in terms of performance (as script variables seem to be repeatedly recreated at runtime)
But yes, a kind of "transient" attribute for block variables would be very useful. Or block to clear.

I made a variant of the block

which read the declaration of a variable from the comment in the custom block header.

I wonder how you made it use the comment to generate them. Could you post a link?

Comment attached to header has a special meaning.

Yes, to make help screens for custom blocks.
Ok.

No, I meant, nothing in 7 is going to make using JS-powered menus any easier than it is now!

Last update today
Block to clear all block variables.

Easier wouldn't be a problem - harder would be the problem

I don't think it'll get harder, i.e., you have to enable JS to do it, and that'll still be true, but no other obstacles. It sounded to me as if you were waiting in the hope that it'd get easier, the way using libraries will get easier in 7.

No - just waiting for it to reach at least beta and preferably RC stage.

Once bitten, twice shy as we say over here