Custom error messages + deserialization errors handling

Hi all,

I would have two questions concerning custom components (in my case, VB in VS2010):

1) Is there a way to replace default error messages by custom ones without adding a string output to a component? (Just replacing the messages in the balloons, or add things to it?)

2) When I update my components, it sometimes breaks the deserialization, some other times it mixes the inputs names with the old ones, or replace the component without any problem. Is there a specific workflow to handle these problems? (keeping hidden old components and do some trick to relink to the new one?)

Thank you,

TS.

Replies to This Discussion

Permalink Reply by David Rutten on January 13, 2012 at 2:27pm

Hi Thibault,

1) you can add your own messages using the AddRuntimeMessage() function. Warnings and Errors will show up in the menu as well as the balloon and the colour of the component will be affected. It is difficult to replace messages generated by parameters, and I'd rather you didn't as that would break UI consistency.

2) Yes indeed, if you change the type or number of inputs/outputs you should always start with a new component. The basic strategy is to rename the old component MyComponent_OBSOLETE or something and set the Exposure flag to hidden. If you use the string "OBSOLETE" (casing does not matter) in the component class name or if you assign the Obsolete attribute to your component class, then Grasshopper will draw the little [OLD] icon on top of it. This will alert users that a newer version of that component is available.

The new component will replace the old one in the interface, and it will need a different ComponentGuid. What this means is that files that contain descriptions of the old component will still be able to load that old component. As of a few versions ago I've implemented an automatic upgrade mechanism, so people can press a button and have all obsolete components in a file replaced by new ones. Unfortunately it's rather a lot of work to write an auto-upgrader so until I figured out a way to make it easier -at least in some cases- I don't recommend spending any time on this.

I know that having the rotting corpses of legacy classes lying around your source code does not feel good. I don't like it much either, but haven't been able to figure out a way around this. Grasshopper itself contains almost a hundred legacy component definitions.

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Thibault Schwartz on January 13, 2012 at 2:37pm