DA.GetData Question for a custom component

Replies to This Discussion

Permalink Reply by David Rutten on January 4, 2013 at 1:33am

Hi Jason,

this is automatic casting. If the user supplies a curve where a number is needed, the curve length becomes the input. You cannot stop this from happening, it is the way Grasshopper is supposed to work. There are two things you can do, the first I think is a very bad idea the latter is a lot of extra work:

1. Instead of Integer and Number parameters, use Generic parameters. Then get the IGH_Goo and see if the user supplied the correct type of data. I don't like this approach because it makes it harder to see for the user what she is supposed to do.
2. Create custom data types that behave like Integers and Numbers but which do not have all the special casting build in.

However I think the best thing you can do is keep it the way it is. Perhaps someone wants to use a Rhino line curve to control the S parameter and this way they don't have to add an additional [Curve Length] parameter.

Ultimately, inside SolveInstance you can find the sources of our ID and S inputs and figure out what parameter types they are. If they are not Integer and Number respectively you can choose to add a warning to your component informing the user of a potential problem.

--

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Jason Lim on January 4, 2013 at 6:21am

Hi David,

Thanks for the reply. I think that I will keep it the way it is as you mentioned (get the parameter type and add warning). However I cannot figure out how to get the parameter types from within SolveInstance.

It seems to me the only way to retrieve the input parameter is through DA.GetData(), but that immediately sets it to varaiables which are already typed e.g. ID.

Could you point me in the correct direction to solve this?

Permalink Reply by David Rutten on January 4, 2013 at 1:05pm

You need to do this once per solution, so inside your SolveInstance method add the following conditional block, inside of which you'll do the testing)

if (DA.Iteration == 0)

{

  ...

}

Come the next release you'll be able to override BeforeSolveInstance() or AfterSolveInstance(), but not yet.

Then you have to actually get the parameter and iterate over the sources. You may want to check for both Integer and Text parameters as people often use Text Panels to input data. You should probably also check for Value Lists, Sliders etc. and everything else that would indicate a valid network. Then, in the future when more objects appear that might make sense in this respect you'll need to adapt your code. It's a lot of work for warning about something which works anyway.

So, testing parameter sources could be done as follows:

IGH_Param param = Params.Inputs[0];

foreach (IGH_Param source in param.Sources)

{

  //Test the type of the IGH_Param or maybe just sneek a peek at the volatile

  //data to see if it's integers, strings or floats without decimal parts.

  //You could look at ComponentGuid, or TypeName fields, you could use

  //reflection to figure out what parameter/data is there etc. etc.  

}

--

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Jason Lim on January 5, 2013 at 7:15am

Hi David,

Thanks for your help with this, I would have no clue how to do this otherwise. I managed to look at the volatile data  and got the type info (tried TypeName, TypeDescription fields and GetType()). It does seem like extra work for not much payoff - i think at the end of the day, users should just be careful what they feed into components.

The next question i have regards the runtime error messages (as I would still like to warn the user of wrong types). What are the differences between error, warning, remark message levels for example? Do they trigger different colour changes in the components (I once got a magenta colored component - which I have never seen before)?

An additional question I have regards keywords. I have several components for example: setAnalogOut, setDigitalOut, getAnalogIn ... I want them to be easily found when using the 'double-click  enter a sear keyword' popup. As a result I pre-fixed all the components with a "UR" at the moment. As a result all the components I provide will pop-up in a list. However I would like to get rid of this prefix and go back to the original names. I thought that by adding keywords instead, this will then be found by the search pop-up. I implemented the Keywords propety  for setAnalogOut component as follows:

    public  IEnumerable<string> Keywords
        {
            get
            {
                return new List<string>() { "UR};
            }
        }

However when I use the searh pop-up it never detects this keyword. Am I doing something wrong here or is the 'search pop-up' (I don't know what to call it) actually looking for other information?

Thanks