I am writing a GH component with a single Parameter input of generic type to accept Points and Vectors [1]. I also have an additional component menu item which toggles the component between two states, and I would like to change the face of the input to showcase this changes.
The parameter is created this way:
protected override void RegisterInputParams(GH_InputParamManager pManager)
{
pManager.AddGenericParameter("Foo", "F", "Target Foo", GH_ParamAccess.item); // FOO just for dev purposes
this.UpdateMessage();
}
And the ToolStripMenuItem handler currently has this code:
// Since the input is Generic, no need to do Parameter changes, just change its face
var param = this.Params.Input[0];
if (this.relative)
{
param.Name = "Vector";
param.NickName = "V";
param.Description = "Translation Vector";
}
else
{
param.Name = "Point";
param.NickName = "P";
param.Description = "Target Point";
}
// Update (and redraw? this component
this.UpdateMessage();
this.ExpireSolution(true);
The problem is, with GH on “Draw Full Names” option, the component first shows up with the full name (“FOO”), on first change goes to the new nickname (“V”) and on successive changes toggles infinitely between P/V/P/V…
So, how can I have the Name stick? Am I missing some redraw call on the component?
[1] Instead of just relying on internal GH_Param.CastTo automatic conversions, I want the input to be generic to be able to test it for types, and display helper messages depending on what the user has plugged in.
It’s a bug with the Draw Full Names option. It could not be implemented properly without breaking the SDK, so whenever the option changes, Name fields are copied into the NickName fields. When the option is unchecked, the NickNames are tested against the Names, and if identical they are reverted to the default nickname by creating an entirely fresh instance of the component.
There are loads of bugs associated with this where names don’t update or revert when you’d expect them to, but if you want to handle it correctly you’ll have to test for the Draw Full Names state and make your code deal with all 4 possible cases (nicknames+points, nicknames+vectors, fullnames+points, fullnames+vectors).
You can access this setting via the Grasshopper.CentralSettings.CanvasFullNames property, and you can also handle the CanvasFullNamesChanged event if you want to respond to it being toggled.
Like so many late UI options I now believe Full Named to be a mistake.
Like so many late UI options I now believe Full Named to be a mistake.
Interesting comment, wonder if you want to elaborate a little on that. I am a full and convinced Draw Icons + No Draw Full Names person, but have seen a wide range of tastes when it comes to this. Why not give users the possibility of Full Names? The more options, the merrier?
For the sake of documentation of this solution, here is what I ended up doing which makes the trick.
Nicknames based on the Grasshopper.CentralSettings.CanvasFullNames
protected void UpdateInputNames()
{
// Since the input is Generic, no need to do Parameter changes, just change its face
var param = this.Params.Input[0];
if (this.relative)
{
param.Name = "Vector";
param.NickName = Grasshopper.CentralSettings.CanvasFullNames ? "Vector" : "V"; // Only nicknames will show up after rename, so a little trick here: https://discourse.mcneel.com/t/changing-input-parameter-names-always-shows-nickname/54071/3
param.Description = "Translation Vector";
}
else
{
param.Name = "Point";
param.NickName = Grasshopper.CentralSettings.CanvasFullNames ? "Point" : "P";
param.Description = "Target Point";
}
}
And the handling of the CanvasFullNamesChanged event
protected override void RegisterInputParams(GH_InputParamManager pManager)
{
pManager.AddGenericParameter("Point", "P", "Target Point", GH_ParamAccess.item);
// Is this the best place to put this?
Grasshopper.CentralSettings.CanvasFullNamesChanged += OnCanvasFullNamesChanged;
this.UpdateMessage();
}
private void OnCanvasFullNamesChanged() => UpdateInputNames();
I wonder if this problem is related to the hassle with the port-names of the ScriptComponents (which fail to update as expected when reanaming port names)?
If so perhaps adding and removing a dummy-name - like I do manually in the above gif - is also a useful workaround in code?
Anyway, your project seems interesting and I will take a closer look at it asap.
I respectfully disagree The more options, the messier, rather. Options are there first and foremost to solve problems certain people are having. If the problems can be solved to everyone’s satisfaction* there’d be no need for options.
Full names for example make the components more informative (but less recognisable) by using more text. In order to accommodate all this additional information the components must become bigger. This causes problems with layout as well. Now if you were to just zoom in on components they also get bigger yet they do not show any more information. I’d really like to explore the benefits of a true ZUI (zooming-user-interface) in GH2. Right now only the variable parameter UI is tied to the zoom-level.
* I know this is not possible, but I’ll settle for 99% satisfaction and 1% grudging acceptance.
The more options, the messier, rather. Options are there first and foremost to solve problems certain people are having. If the problems can be solved to everyone’s satisfaction* there’d be no need for options.