cpcallen
commented
4 weeks ago Hi @FranciscoCaetano88. As I noted in our discussion in the forum, a better approach for your particular situation is probably to make the blocks non-shadow and modify the dragging strategy to work accordingly. That said, however:
The request that it be possible to access a block's context menu even when that block is a shadow seems reasonable and I think we should consider making this change. At the moment it is not possible to access a shadow block's context menu, because when a gesture begins on a a shadow block, unless that gesture is a click, the gesture is instead treated as targeting the parent block; to make it possible to access the context menu this gesture would also have to be excepted from the target-parent rule too, and as this would be a breaking change it will require some careful consideration to ensure that it does not create unexpected difficulties.
Would you be able to provide some screenshots of your current use-case, to provide a clear explanation of how this feature would be useful to you?
Check for duplicates
Problem
I'm working on creating a function block using the new version of Blockly, where users can dynamically add or remove multiple arguments that themselves are shadow blocks. Most blocks shouldn't be able to connect to this inputs but there are a few exceptions. I've also implemented a custom dragging strategy that allows new argument blocks to be created by dragging this shadow argument blocks.
Now, I wanted to enhance the shadow blocks by adding a context menu that allows users to edit or remove the selected block. However this is not possible due to a rule in the gesture class that makes the target of every shadow block its parent. I experimented with making the argument blocks non-movable instead of using shadow blocks, but this approach didn’t work with the dragging strategy.
Request
I would like to be able to add a custom context menu to shadow blocks.
Alternatives considered
No response
Additional context
No response