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.
Panel and slider properties.gh (23.5 KB)
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:
Panel and slider properties_getconnected.gh (24.0 KB)
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.
I’m positive the McNeel team could design a solution that circumvents both problems in the future. 
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:
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.
In the end it looks something like this:
So yeah Sunglasses and SnappingGecko really help for clean definitions.
But to come back to your point, yes, I think it would be nice to have a built-in way to set sliders and so as User Keys/Values!
This topic might be helpful
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.
One can probably script that fairly trivially, until a “more” native solution appears:
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.
Why does this fail to output a result in a python 3 script component?
240814_GetCanvasObjectProperties_00_python-3-fail.gh (12.5 KB)
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.
Ok, thanks for the information. It works with IronPython. My brain doesn’t like the ‘OLD’ tag on the python components… 
FYI: The type shows as Grasshopper.Kernel.IGH_Param
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:
Something else I noticed with Metahopper’s components is that they aren’t really suited to create trees from lists.
Notice the items are all merged under a single index at the end.
E: Also, the script doesn’t function with multiline data panels yet:
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:
