How to register input/output params dynamically (C# -> VS)

Hi,

I'm working on a F# script component written in C# for Grasshopper. What I have managed so far is to compile code in F# in Grasshopper. Right now I'm working on a implemented script editor. I'm stuck in adding and removing Parameters dynamically.

My idea, was to define them inside the editor. The problem with this approach is, that I cannot "reregister" my input/output params. Is there any chance to get it done or do I need another approach to handle this?

I'm using the "generic" parameter but there is also a "script" parameter but I don't really understand how to use this.

for me, it is always one of the most challenging part to handle grasshopper components and its layout. Are there any tutorials out or example code to get a deeper info of custom component creation (..and not only the "basic" ones)?

Replies to This Discussion

Permalink Reply by Daniel González Abalde on June 7, 2016 at 7:49am

I'm not sure I understood correctly, but this works to add a parameter but not to remove it. I do not have more time, I hope this serves as something.

Private Sub RunScript(ByVal Add As Boolean, ByVal Del As Boolean, ByRef A As Object)
Try

Dim params As GH_ComponentParamServer = Me.Component.Params

If Add Then
Dim newParam As New Grasshopper.Kernel.Parameters.Param_ScriptVariable()
newParam.Optional = True
newParam.Name = String.Format("Param_{0}", Params.input.count)
newParam.NickName = String.Format("Param_{0}", Params.input.count)
params.RegisterInputParam(newParam)

Params.OnParametersChanged()
' Me.Component.ExpireSolution(True)
End If

If Del AndAlso Params.Input.Count > 2 Then
params.UnregisterInputParameter(params.Input.Last())
Params.OnParametersChanged()

' Me.Component.ExpireSolution(True)
End If

Catch ex As exception
rhinoapp.WriteLine(ex.ToString)
End Try
End Sub

Attachments:

addparam.gh, 5 KB

Permalink Reply by David Rutten on June 7, 2016 at 8:22am

If you plan to have a variable number of parameters on your component you should implement the IGH_VariableParameterComponent interface. You can just return false and null for all methods if you do not want to show any UI for addition/removal, but just implementing the interface will mean your components will get properly (de)serialized in all cases. Without it, the component assumes that the constructor will set up all inputs and outputs and reading files will no longer work correctly.

As Daniel mentioned, using the RegisterInput/OutputParam methods can be used to add input or output parameters to a component. Also important is that you always call Params.OnParametersChanged whenever you are done with making changes.

However you are never supposed to do this from within RunScript or SolveInstance (bad Daniel! bad!). Changes to the topology of components and changes to wires can only be made when a solution is not running. In your case, I'd recommend making all changes when the 'Add to input' or 'Add to output' buttons are pressed.

The difference between Generic and Script parameters is quite significant, although you can probably make it work with both.

Generic parameters are not fussy about the data they contain, so if you don't know the type of data the user wants to provide, it's a good way to go. Script parameters were specifically designed to be used as inputs for script component, so I recommend you try these first.

Script params will take some steps to protect data which may be shared amongst multiple components in a GH file. <obnoxious>Scripters after all cannot be trusted with important data, only people who use Visual Studio are real™ programmers.</obnoxious>. Script params also offer some type casting mechanisms to standard types (bool, int, double, string, Brep, Curve, Point3d, etc.) and access modifiers (item, list, tree).

Permalink Reply by Daniel González Abalde on June 7, 2016 at 9:21am

hehe, I have zero fear of being wrong, and I have many rooms still no light in this building. If I stumble, at least one knows where it comes from my whimper.

But talking about this. Please David, make for the next version you can choose the type of access to the parameters of the UserObject. In jewelry there are many very common algorithms, the UO are necessary, but without this feature sometimes becomes too cumbersome for people with less than intermediate level.

Do you have any new ideas for UO in GH2?

Permalink Reply by David Rutten on June 7, 2016 at 11:41am

UserObjects are just regular objects in a specific state. Do you mean clusters? Or script components?

No worries about being wrong, I'm glad you help so many people out. I'm wrong all the time when it involves software I didn't write myself.

Permalink Reply by Daniel González Abalde on June 8, 2016 at 8:30am

I wondered about clusters. I find it very interesting to think about the algorithms as identity or object. The clusters work, but unable to control the flow of input parameters (the type access) is like an incomplete function. For example, a cluster has a parameter with access of element and another with access of list. If the first input you give a list of "n" elements, then the cluster should be executed "n" times, and each solution with a single element.

This would be possible for GH2?

You see the problem? I can explain it better if necessary. The solution of an adaptive algorithm to all types of access often is too bulky.

Permalink Reply by David Rutten on June 8, 2016 at 10:43am

This would be possible for GH2?

It's absolutely possible, I just think it's a terrible idea. There should be no difference whatsoever between a bunch of components and a cluster which contains those same components. If the components get to behave differently when they are inside a cluster, it makes life more difficult for everyone. For me because I now have to start looping clusters and aggregating output data, for cluster developers because they can no longer design a cluster in place and only compact it later, and for users because stuff now works in two different ways.

If there is going to be a feature which allows people to chop up data and perhaps loop a set of components over those chopped up fragments then that feature should come in the form of a component or other canvas object, it should not be hidden inside the cluster interface. Benefits of this approach are:

Works even without clusters.
Does not hide important structural information.
Uses existing UI paradigms.
Opens the door to other types of looping functionality, perhaps even recursive logic.

I understand it would be nice to forget about data structure when designing a function, but I don't see why this niceness needs to be dependent upon clusters.

Permalink Reply by Andrew Heumann on June 8, 2016 at 3:57pm