Adding shadow inputs to procedure callers

[Laurens Valk]

Hello!

I am trying to add numeric shadow blocks to procedure callers, to make it easier for users to call functions (inspired by Scratch and MakeCode).

I have been able to use mutators and shadow blocks in various custom blocks, but I am not sure how to best to it with procedurer callers.

Things I have tried (in many variations):
- I originally started with legacy procedures and got it working with "quarkConnections", but switched to "block-shareable-procedures" since it nicely breaks down the various mixins.
- Hooking into procedureCallerUpdateShapeMixin.updateParameters_ or createArgInputs_ to add zero-valued shadow blocks after they run.
- Using the event handler to add to add zero-valued shadow blocks on any change when an input is empty.

This sort of works, but the shadow block values will reset to zero. If I understand correctly, these steps run before child blocks are loaded. And repeatedly so when the definition block is moved or changed. (I'd love to know why mutators seem to completely rebuild on moving, but maybe that is a question for another time).

This makes it tricky to keep track of the shadow block values. I've also tried something similar to the "argsMap_" method, to cache the numeric values and "reattach" these as needed. But since shadow blocks can't exist without a parent, this causes trouble when moving the argument order in the mutator dialog.

In the process, I reported a few upstream issues (https://github.com/google/blockly-samples/issues?q=author%3Alaurensvalk), so now you know how I came across those :)

It would be awesome to get a few hints on the recommended way to do this. Thanks in advance!

If you think this is a useful (optional) addition, I would be happy to help get the result back into "block-shareable-procedures" for others to use.

[Neil Fraser]

I've been thinking about this for the past day, and have an unusual suggestion.  Have you considered adding an event listener to your application that looks for creation events belonging to the function caller, which then creates the shadows?

--
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+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/blockly/4e3f815d-0186-43d6-b40f-8d9cef1a318cn%40googlegroups.com.

--

Neil Fraser, Switzerland
https://neil.fraser.name

[Laurens Valk]

Thanks Neil, so nice to hear from you.

I've tried event handlers at various stages, also in combination with the mutator approach. It does work, but I ran into issues with the input re-attach step, as shadows cannot temporarily live on the workspace as orphans (I think) while the mutations happen (and while the blocks in the mutator blocks are dragged). I think I have to do some more digging to properly understand the creation/destruction/reshape steps for mutators, as some of these appear to happen more often than I would have guessed, such as during a simple move.

Pending the review of the other issues reported upstream, I'm going to give this a fresh look with a slightly simpler mutator approach for the caller. Changing input order will still be allowed, but I'll start by not re-attaching the user inputs. When that works, I'll give it another go with the official block-shareable-procedures plugin. By comparison, the MakeCode and Scratch implementations of procedures do appear to have shadow inputs on callers but don't allow changing the argument order at all, so maybe it's an older problem.

For context, I am working on a Blockly-based interface for Pybricks (https://code.pybricks.com/, https://github.com/pybricks). Hopefully in a few months, you'll be able to code your LEGO Trains/Trucks/Robots/contraptions with Blockly, and have the resulting code run autonomously (something previously only reserved for Mindstorms). We've got the firmware/sensors/motors/editor/connectivity all sorted; the Blockly-based interface is the final step. Thank you and the whole team for developing Blockly and maintaining it so actively!