How do you code?

Hi everyone-

So I'm curious about general scripting practices employed by all of the .NETers here. I should give some background: I've been programming for many years now, starting in my old work, where I performed data analysis...for this I used a lot of VBA for Microsoft Access, executing SQL, managing recordsets, loops, and whatnot. So when I went back to school to study architecture in 2007, I naturally started using as many computational approaches as I could. That said, I am completely untutored...pretty much everything I do is based on some mixture of luck, intuition, and picking up ideas from others. So I've never really operated in a truly native, scripting-only environment.

As a result in almost all cases I just work directly in VB components on the gh canvas, and for the most part this works fine for me. In fact, I very much enjoy the soft edges between visual and text-based computation afforded by the environment. That said, lately many of the scripts that I have been working with have been getting quite large. Custom classes and functions for some my projects have simply become unwieldy, and going back and forth between the canvas and the script just feels very inefficient. In my early dabblings with making components, it's become clear to me that Visual Studio is a much more robust place to work with and manage loads of code. But how does this work when you're going back and forth between the script and other objects on a gh canvas? does it at all? is there any way to operate in both simultaneously and have an efficient workflow between them? I'd love to hear from other people who use a lot of code so I can try to understand their approaches and hopefully use them to improve my own workflow.

thanks and best regards,

Dave

Replies to This Discussion

Permalink Reply by David Rutten on March 1, 2013 at 8:16am

Visual Studio (or some other .NET IDE) is the only real choice for large project development. It is possible to debug from within VS which is a major benefit, however you will have to restart Rhino and Grasshopper between compilations which can get frustrating if you're not making headway on a specific bug.

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Thibault Schwartz on March 1, 2013 at 8:59am

I totally agree with David, one trick I also use times to times to play with best of both worlds is to test portions of code that I am not really sure about directly in the VB component, and then when I have solved the errors, I put it back in the VS project (cannot be done with everything but if it is just geometry it's OK). Can be useful... Otherwise, I am often using multiple addRuntimeMessages or outputing a log and some test objects from the component to check where things are wrong. I never used the VS debugger for that, maybe I should...

Permalink Reply by David Rutten on March 1, 2013 at 10:30am

You definitely should, debugging is a must-have skill for any Visual Studio developer.

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by David Stasiuk on March 4, 2013 at 1:24am

Thanks for the replies guys. So at the risk of sounding ignorant...you basically develop all of your more significant projects specifically for compilation as either components or component groups, published as GHAs? and then set the "build output path" to simply be the components folder and overwrite any previous GHAs as they are built, tested and rebuilt?

Do you know of any examples of vs projects where multiple components are generated from the same project. I have using the wizard, which is amazing, but also which seems geared to work toward a single component output. What I'm aiming to do is have a series of components where I could develop a number of custom classes that could be passed from the output of one component to the input of another.

Permalink Reply by David Rutten on March 4, 2013 at 3:25am

Here's the basic idea of GHA projects:

They have to be .NET assemblies because Grasshopper loads them.
They have to be DLL files with the extension GHA.
They are typically made using either VB.NET or C# on Visual Studio, but other languages and other IDEs are definitely possible.
If you're developing for Rhino5 only, you should target .NET 4.0, if you're developing for Rhino4 as well, you should target .NET 3.5
A GHA file can contain any number of classes (even zero) that inherit from GH_Component. You'll have to supply the details for each one (icon, name, description, where it belongs on the toolbar and of course the actual algorithm) but the loading and UI and (de)serialization is taken care off by me.
A GHA file can contain any number of classes that implement IGH_Param (or which inherit from one of the abstract implementations such as GH_Param<T>, GH_PersistentParam<T> and GH_PersistentGeometryParam<T>). If you want to have your own data type for your components you'll probably want to write a parameter for it.
A GHA file can contain any number of classes that implement IGH_Goo (or one of the provided abstract implementations). This is the actual data type itself. In Grasshopper proper examples are GH_String, GH_Integer and GH_Brep.
A GHA file can contain any number of classes that ultimately implement IGH_DocumentObject. This is for stuff that is neither a component nor a parameter. Think Scribble object.
A GHA can contain any number of classes that inherit from GH_AssemblyPriority. These classes are guaranteed to be loaded first so things like License Validation can be done early on.
A GHA should contain (not technically required but it should be there) a single class which derives from GH_AssemblyInfo where you provide information about the GHA file itself, i.e. who wrote it, what it's called, what sort of license it has been developer under, the icon etc. etc.
A GHA can contain references to any other .NET assembly and of course all the custom code you want.

This GHA file is then created anew every time you compile the project in Visual Studio. You can only override existing GHA files if they are currently not loaded by any application, so if Grasshopper is running and has loaded your GHA then you cannot compile. You'll need to shut down Rhino,then recompile, then start Rhino and GH again.

By using the GrasshopperDeveloperSettings command you can add a GHA loading folder so that Grasshopper always loads your GHAs from your compilation bin folders.

There is further information in the SDK Documentation which can be downloaded via the Grasshopper help menu.

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by David Stasiuk on March 4, 2013 at 4:33am

Outstanding. Thanks so much...between this, the documentation and various existing discussions on the forum I'll be on my way.

RSS