I am one of those who rely on over-riding all of the nicknames on every component input and output.
This allows me to immediately know the meaning of the expected data at each input as well as the meaning of the result at each output.
Tracking down mistakes, adding functionality, and returning to old definitions years later are all much much easier with this practice.
I love the way this works in GH1 for most of the available components. It would be a dream come true if GH2 allows this on every single one.
There’s actually effort that went into making certain parameters not renameable. Like when input names include an index number or path, if it tells you the wrong number it may be really confusing.
However I do appreciate that limiting your ability to name things as you please is just another way to make something more confusing.
I think I can probably remove the naming restrictions everywhere, and add a secondary naming system which kicks in only when there is no custom name set on an input or output. That way if you choose to assign your own name to an input, it’ll override the default name, but I can still tell when a parameter name is generated through code or set by the user.
Logged under RH-68308.
2 Likes
Okay, seems to work. If the component now has smarts to assign dynamic names to parameters it just assigns those to a FallbackName. The user gets to specify the UserName, if the UserName is not set, the FallbackName is used in the UI instead.
So in this example, all the “M{i}” names come from the fallback field and do not appear in the pop-over name textbox.
1 Like
Immense thanks David!
I sincerely felt that the value of the custom names was diminished if it was not universal to all components.
Your solution is logical and elegant as usual.
