Overriding the GUI on the "Value List" Component

Replies to This Discussion

Permalink Reply by Danny Boyes on January 20, 2014 at 12:40pm

This doesn't answer your question specifically but have a look at andrew's Human plug-in where he has a component Dynamic Value list based on GH's

Permalink Reply by David Rutten on January 20, 2014 at 12:48pm

The Value List is actually a parameter, not a component. Most special objects are parameters (Toggles, Buttons, Sliders, Dials, Panels, etc. etc.). Parameters can have a maximum of one input and one output, which is sufficient for most special objects. The exceptions are Legend and Gradient btw., those are actual components.

The problem is that components are difficult to change. There's an awful lot of code involved in keeping the inputs and outputs correctly linked and positioned. It can be done, but it aint easy.

If you provide custom attributes for a GH_Component, you must do the following things:

• Either inherit from GH_Attributes<T>, GH_ComponentAttributes or GH_ResizableAttributes.
• Make sure all input and output parameters have GH_LinkedParamAttributes and that they know who the parent object is.
• Override the AppendToAttributeTree method and append the component, all inputs and all outputs to the list.
• Override the Layout method and make sure all parameters are correctly positioned around the component box. There are utility methods to help with this, but it's still tricky. Have a look at Attributes.GH_ComponentAttributes.LayoutInputParams for example.
• Override the Render method and make sure everything is drawn in the right channel. 

You may also want to override the RespondToMouseDown or RespondToMouseClick methods if you want to display a popup menu.

--

David Rutten

david@mcneel.com

Permalink Reply by David Rutten on January 20, 2014 at 2:10pm

Parameters are much easier to work with. They have one input grip, one output grip, they only collect data (plus maybe some post-processes such as grafting, flattening, expressions etc). Components are aggregates of objects. There's the component itself which does all the work and it also maintains a collection of linked input and output parameters which all have to work together and be drawn together.

If you want an object with two inputs, then you have to use a GH_Component. If you're willing to only have a single input and single output, then it becomes a lot easier.

--

David Rutten

david@mcneel.com

Permalink Reply by David Rutten on January 20, 2014 at 3:05pm

Well creating a standard component is quite easy because all the cumbersome work is done by the base class (GH_Component). If you want to change this default behaviour then you have to start writing a lot of annoying code.

Writing new components is something I tried to make as easy as possible because I thought it was pretty much all that plugin developers would want to do. That has turned out to be a serious underestimate, but for the time being writing your own IGH_Goo, IGH_Params and making GH_Components non-standard is difficult.

--

David Rutten

david@mcneel.com

Permalink Reply by Tree on August 13, 2015 at 9:56pm

David,

I'm interested in this topic.  Are there any examples, and or documentation, available?

I've hooked up a form to a component and am controlling selections through the form but I'd like to find a more elegant solution / GUI.

Permalink Reply by David Rutten on August 14, 2015 at 2:45am

There are no examples of overriding GH_Component attributes, but in the Grasshopper SDK help you can find an example of overriding IGH_Param attributes. (See Custom Attributes)

Permalink Reply by Tree on August 14, 2015 at 4:30pm

Will do!