Collapse group inputs


I’ve been testing out the new collapsable groups in Dynamo 2.13 but once collapse, Dynamo shows inputs for nodes that already have a default value and require no input.

Is there a way to hide these inputs in the collapsed groups without manually specifying the same default value?

1 Like

Not that I’m aware of, but I agree it would be nice.

@solamour @jacob.small any chance this could be implemented? Still happening in Dynamo 2.17.

Hi @Paul_Wintour - My apologies, I never saw this. It’s a good idea, so can definitely log it :slight_smile:

Will not be in 2.17 or 2.18 (As we are releasing that Core version immanently), but can talk about it for 2.19.

Preferably this would have some kind of control at the port (or node) level. There may be times where you still want the option to provide a value for optional inputs in a group.

1 Like

@Nick_Boyts port control is super granular, so we’ll need to balance that vs. the quick clean up option that I believe Paul is after.

If running this via Code Blocks could give granular, would that cover it? As in - normal nodes can get globally covered, or covered at the macro-group level, and individual things that “are different” would be Code Blocks?

I might be missing something… optional inputs are only available on nodes right? Is there a way to have a code block input that still provides a value if none is given?

There isn’t, correct. You can set an object type to a variable, and call that, but not have a default that is optional :slight_smile:


I was suggesting that Code Block inputs (In the case above of val) could not participate in the collapsed group request from Paul.

Gotcha. Yes, I think that makes sense for code blocks since they should be explicit values in that case anyway.

1 Like

Hi @Paul_Wintour @Nick_Boyts Thanks for the suggestion!
Here’s a mockup that we are proposing. You can either control on a per-group basis thru the group menu or on a graph basis thru preferences. We would love to hear what you think. Thank you!


Love it @jingyiwen!

Only suggestion would be to use something like “Optional” or “Default” since “Unused” could be construed as “not having a value” or “not utilized”.


Looks good to me.


Thank you both so much for the feedback! @Nick_Boyts @Paul_Wintour