For use with the User Text components, I would like to see two components that can read the properties of panels and sliders. That way, you can use the (nick)name of a panel/ slider and their values as Keys and Values respectively. Metahopper has a component that works for sliders, however, you cannot directly feed in the slider, nor does in expire when the slider’s name is changed – meaning you have to reselect it.
I usually prefer to use the “Get connected object” from Metahopper. That way you don’t have to select an object first using a button and it will always work.
You can then also use Object Info to get the nickname of any object, including a panel. The value is just the same value coming out of the panel.
That’s exactly the setup I wanted to have/ show, thanks!
E: Unfortunately this still requires a manual update (or a trigger component) after you change a nickname, so the feature request remains.
Once again, Metahopper has thought of that and gives you an “expire object” component. Just select the object and always set it to true. It will now always update automatically:
ps: I noticed that if you leave the expire object toggle on True all the time, it seems like GH doesn’t save properly. Pretty sure this is a bug in Metahopper. Also it will really slow down your definitions, so use with caution.
Not sure. The things that Metahopper does are VERY specialised use-cases and I doubt they will ever be part of Grasshopper natively. They are just too “hacky” and you usually just need them for some workaround.
Why do you need the user text to follow the name of the panel? I kind of suspect that you are actually trying to do something that can be solved differently. What is the use-case for this?
It’s reducing the number of names I have to set across the canvas, if the value is already on the slider and the key name as well, why not utilise them? Makes managing them easier.
Take this example (top group), I usually replace sliders with panels whenever I have the slider inputs appear elsewhere (so I can see where the values come from, a parameter, but don’t have the wire clutter). If I could leverage these sliders directly (bottom group), it makes for a more elegant script organisation. And there would be no way to introduce typos since everything references a single source slider.
Okay, yeah that makes sense. I don’t really use User Key/Values so much, except for where I am storing some information for a script to use, but not for anything else.
Btw, for keeping definitions clean and easy to understand I usually do the following:
Create a new slider and name it
Create a new parameter and give it the same name
I have the Sunglasses plugin set to only show names on Parameters
That way you have named parameters
Then I place one to the right of the slider
Every connection to the definition now goes from the parameter, not the slider
Everywhere I need a certain slider value, I copy the named parameter of it and connect those.
Same for outputs
That way you will only ever see named parameters going into or out of a section.
It takes a little while longer and I only do this for scripts I know will be updated/developed a lot and/or kept around for a long time.
I do the same with panels, which I give a red colour for a new parameter and a less saturated red for a parameter value which stems from a slider. I set their wire visibility to invisible and colour the panel using Metahopper. It gives the same result, be it with a coloured panel that I can name and spot more easily than a parameter.
Changing the nick name of canvas objects does not appear to expire downstream components. I wonder if that’s by design. Either way, I’m not entirely sure how one would add that to the scripts above (e.g. they would have to listen to changes). But it might be equally trivial.
I don’t know (still not using Rhino 8). Try uploading the file and maybe someone can have a look. Edit: From memory seeing issues being reported here on Discourse, I bet it’s the type(obj) check on line 9 that isn’t returning the correct type (i.e. GH_NumberSlider). Generally speaking, I wouldn’t recommend using CPython for all this meta programming stuff, or for interop with .NET in general (i.e. due to type issues). At least use IronPython, or better yet (if your goal is predictability and performance), stick with GhPython for now.
Is it possible to make the component function like a merge component with (+) and (-) buttons to add/ remove inputs when you zoom in? That would allow me to rearrange them.
It is, but not trivially so. Especially with a scripting component.
You can edit this within the script, which is very trivial (i.e. reorder the comma separated items on line 11).
Edit: Sorry I think I misunderstood. We can also iterate the inputs parameters. And since GhPython is already a ZUI component, this is in fact also a pretty trivial edit:
E2: Ideally, I’d like to have something like this where the first item can be matched with a geometry attribute and the other values can be used by the script: