variable number of arguments ?

[jl05140]

Hi there,

In order to implement in one block something like the print function,

that accepts an unlimited number of arguments,

what kind of block should I define ?

I have experimented with a "print" block with only one input value and used arrays or linked lists as argument.

But I am facing difficulties because my UI must be close to the literal usage of the print function.

More precisely, the print block must be rendered inline, looking very similar to "print(foo, bar)" for example.

Then when dragging a new "string" block over it, the acceptable drop locations would be

- between '(' and "foo"

- between ',' and "bar"

- between "bar" and ')'

When dropped, the new block would be inserted accordingly in the list of arguments. The result would read one of

print(string, foo, bar)

print(foo, string, bar)

print(foo, bar, string)

Where should I go to implement this drag and drop UI ?

(I am ready to extend blocky as far as it stands reasonable)

TIA

BTW "print" is just an example.

[Andrew n marshall]

Hi there,

We do support variable arguments through mutators, however we do not have any sort of "pending drop location" event to trigger it and get the specific behavior you are looking for.

You will find the mutator docs here. All mutateable blocks begin with a mutator assignment in the JSON definition:

{
  //...,
  "mutator": "my_vararg_mutator",
}

Because of the extra code that get executed, each platform has a slightly different way of writing the mutator. I'm going to assuming you are using the web APIs.

For your needs, the text_join_mutator is a great example. See source.

At the very least, you'll need domToMutation(..) and mutationToDom(..). The former will read the count of arguments from the <mutation> element and construct the appropriate inputs. The latter will write that information to <mutation> when serialized.

If you use our mutation UI, you can keep following the text_join_mutator as an example. You will add the compose(..) and decompose(..) methods to populate and apply the UI's changes.

You can also do this from various event listeners. For example, math_number_property block uses the math_is_divisibleby_mutator (source) to add a input for the divisor when the field changes. Some developers prefer having buttons on blocks (image fields with click events) as the mutation UI.

If you are committed to your vision for a UI, please follow up. We can probably point you to the right area of the code for a "pending drop location" (and it might have other uses worthy of a pull request, such as help systems). Adding and destroying block inputs during a drag operation will add some unique challenges.

If implemented, I'm very curious about the usability of such hidden connections. I would guess a number of users might not discover the possibility.

--
Andrew

--
You received this message because you are subscribed to the Google Groups "Blockly" group.
To unsubscribe from this group and stop receiving emails from it, send an email to blockly+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.