Send / Receive trigger in Grasshopper (and others?)

When the number of connectors (senders / receivers) grow in a GH definition, it would be useful to have the option to plug a “button” component to trigger them all at once. This may be useful in other software packages too?

3 Likes

This would also help when trying to receive from an external UI window like ETO forms or Human UI. Any workaround in GH for this with current components?

Hi @FeRnB @Andrei

It seems this thread fell through the cracks and we never got to answer it. Sorry about that.

You mean like this? Just use a “stream filter (native gh node)” and a toggle and you should be good to go.
2023-09-28 11.03.33

If a toggle is not desired and you want it to happen "at the press of a button, then the only thing you’d need to do is swap the normal send/receive nodes for sync send and sync receive nodes respectively.

This will lock the UI and ensure that all nodes have finished sending before the button automatically switches to false.

MultiSendButton.gh (13.0 KB)

Hey Alan! Nice workaround indeed. But this won’t work when receiving a specific commit the user picked out though right? Might work with stream autoreceive which will grab the latest commit, but cant think of a way to receive a previous commit via external trigger

What’s your use-case for this? You want to receive the current and the previous commit?
Or is your goal to somehow provide the user a way to select multiple commits from a list?

If the user has already picked out the commit they want to receive, the receiver will accept commit urls too

Hey!

Usecase looks somthing like this: we are having the user select a single commit in a Human UI interface and press a button that would trigger the receive in GH. The script then does some analysis on whatever is received. The user will only interact with the script via the Humain UI and not the GH canvas itself.

Seems like autoreceive workflow on the Receive component is disabled when feeding commit URLS.
image

Oh I see! I’ll confess I did not remember the receiver had this capped. We made this because “auto-receive” will actually listen to changes on a branch and receive the latest commit from it automatically. This did not make much sense at the time as a url pointing to a single commit will never change, though I do acknowledge that “auto-receiving” when you first plug in the URL does make sense… I’ll raise it with the team!

Meanwhile, can I suggest you just swap that Receive node for a Sync Receive instead? Those were made to enable automatic GH runs (such as using Hops/Rhino.Compute to run a gh definition) and will receive everytime the solution is computed.