algorithmic modeling for Rhino
if it's just a matter of renaming parameters, you can copy your definition, paste into a text file, find-and-replace, copy it all, and paste it back into your definition.
If you're only interested in renaming parameters/inputs, you might try to find and replace this string:
<item name="NickName" type_name="gh_string" type_code="10">CONTENT TO REPLACE</item>
or if you wanted to do it a smarter way, you could write a script to iterate over GrasshopperDocument.Objects and modify the objects directly that way.
Thank you Sir!
That was an unexpected approach!
Tried it and succeeded, but I am a teeny bit scared of cutting an entire definition and pasting it back again (what could possibly go wrong?).
Are you doing this on a regular basis?
Encountered any problems?
Thank you for a interesting reply!
//frans
It is somewhat dangerous, performing a text replace on all the xml data rather than just the names may result in invalid xml. If you're replacing "a" with "_a", you're going to totally hose the xml. However replacing strings that are unique should be fine.
I am probably going to ditch xml support entirely in future versions, so this approach will not work forever. Luckily there are good alternatives, although they do require some coding. It is reasonably trivial to write a find/replace algorithm for nicknames and to even include some filters about which objects ought to be included in the search and which not.
Since I can/should no longer add new features to GH1 I'll have to do it through a VB component, which means a lot of extra code. I attached a GH file with a VB component that shows a Find|Replace window with options and a button. The other components are just there to test the renaming.
The renaming can be limited to components only (i.e. no sliders, no toggles, no panels etc) and you can also ignore input and output parameter by limiting the replace to top level objects only.
If objects are renamed, the operation will be undoable.
--
David Rutten
david@mcneel.com
Wow, this is awesome!
This will really make a difference for us, since we are using nicknamed wireless parameters a lot for keeping track of data when modularizing definitions. And sometimes you just give the parameters names that starts to feel stupid after a while.
I hope this feature will find its way in to a GH2 release, maybe combined with a possibility to instantiate a parameter through its nickname, connected to the same source as the original?
Enough of wishing things for today, thanks for being awesome!
//frans
Welcome to
Grasshopper
Added by Parametric House 0 Comments 0 Likes
Added by Parametric House 0 Comments 0 Likes
© 2024 Created by Scott Davidson.
Powered by