SDK changes and new features in Grasshopper 0.9.0050

Dear GHA developers,

Hopefully in a few days Grasshopper 0.9.0050 will be released. The last two hurdles (the installer and assembly version rolling) are now working so once I'm certain there are no other serious bugs we're good to go.

Although there are plenty of potentially breaking changes to the SDK, I'm boldly assuming that (almost) none of them will affect your typical GHA library. If this is not the case I'll do my best to try and add some legacy support for features that have changed soon after the initial release.

There are however a few new things that you probably should support. In this discussion I'll outline several of them. Some of these are already in the current release.

Replies to This Discussion

Permalink Reply by David Rutten on April 19, 2013 at 8:22am

Before/After Solution

It is now easier to do stuff before and after any calls to SolveInstance during a single solution. There are two overridable methods on GH_Component called:

BeforeSolveInstance()
AfterSolveInstance()

You no longer have to look at the DA.Iteration field and you no longer have to guess which call to SolveInstance is the last one.

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by huaxiamengqing on April 19, 2013 at 10:58pm

I am dying for using the new version. awaiting .....

Permalink Reply by David Rutten on April 24, 2013 at 6:18am

Component Keywords

It is now possible to override the Keywords property on all IGH_DocumentObject derived classes (like components and parameters). Return a collection (List, Array I don't care) of strings that will be traversed when searching for objects in the double-click-on-canvas pop-up window.

For example the [Curve CP] component is now actually called [Curve Closest Point] and the Keywords property on it looks like:

public override IEnumerable<string> Keywords
{
get
{
return new string[] { "CP", "Nearest" };
}
}

because searching also works on partial hits so if people search for "near" it will be covered by "nearest".

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Steve Lewis on April 26, 2013 at 10:14pm

David any idea when we can expect this release? I suspect i have to rewrite a lot of code.

Permalink Reply by David Rutten on April 27, 2013 at 5:26am

What sort of code do you expect will go stale?

Although there are breakages to the SDK, if a certain function no longer works then I can always try and put it back in for legacy purposes.

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by David Rutten on May 1, 2013 at 3:53am

Loading GHA files

A new way of loading non-standard GHA files has been added to make it easier to install 3rd party GH plugins. In addition to putting a GHA file into the %ApplicationData%\Grasshopper\Libraries\ and changing the core xml settings to add a custom load path, a *.ghlink file can now be put in the appdata folder with any number of absolute paths.

GHLINK files are just standard text files with the following rules:

File extension must be *.ghlink
Whitespace at the start and end of every line in the file is ignored.
Lines starting with # are ignored.
Lines starting with // are ignored.
Lines containing valid folder paths are parsed and the folder indicated will be traversed for GHA files. Subfolders will not be included in the search.

So for example, let's say we've written a Rhino plugin project called Fruitbat which includes a FruitbatComponents.gha file. Since it's not just a Grasshopper plugin, we don't want to put it the %ApplicationData%\Grasshopper\Libraries\ folder. Instead, our installer will put all the associated files of this project in C:\Program Files\AwesomeSoftwareCorp\Fruitbat\

In order to get GH to load FruitbatComponents.gha, we need to add a text file at %ApplicationData%\Grasshopper\Libraries\Fruitbat.ghlink with the content:

#Link to Fruitbat components

C:\Program Files\AwesomeSoftwareCorp\Fruitbat\

Capiche?

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Mitch McEwen on May 10, 2013 at 12:21pm

Is 0.9.0050 compiled on NET 3.5 or NET 4.0? I am wondering for coding c# component libraries in Visal Studio - can I switch to NET 4.0 now?

Thanks

Permalink Reply by David Rutten on May 10, 2013 at 1:00pm

4.0 Rhino5 requires a minimum of .NET 4.0 so I upgraded.

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Mitch McEwen on May 10, 2013 at 3:10pm

Excellent timing. Thank you.

Permalink Reply by Mitch McEwen on May 13, 2013 at 9:55am

David,

Just FYI I have been working in c# on a component library with a 3rd party .NET dll using 3.5 NET. After this thread I switched to 4.0 and get an error about not being able to load the Assembly and Exception from HRESULT: 0x80131044

I switched back to using / referencing the 3.5 NET dll and everything works fine. If there's any possible explanation I am interested.

Permalink Reply by David Rutten on May 13, 2013 at 12:44pm

Seems like the problem is strongly named assemblies (or lack thereof). Is this of any help?

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Mitch McEwen on May 13, 2013 at 3:09pm

No, it's not actually that, though the error messages often mention Strong Name Assemblies (even when the problem is dependent dlls being x86 instead of 64-bit). I verified with the Developer Command Prompt in VS that both the 3.5 and 4.0 NET dlls are Strong Named.