Debugging within the VB Script Component/Visual Studio: Setting a Break Point

I am new to VB scripting and was dabbling with some scripting for Excel. I noticed that their scripting editor had a host of debugging features which seem essential, especially to someone starting out. Is there a way to set a break point and use a command window in order to Step through lines of code and access the value of variables, dimension & sizes of arrays etc?

Is their a way to use Visual Studio in order to debug scripts? I believe it has all the debugging features, but since the VB component is a "module" within a plugin, and the values are coming in through the grasshopper solution I think this might be hard.

Does anyone know how to set up Visual Studio to import whatever namespaces etc it has to import?

Does anyone have any debugging types for working within the tools given to use with the grasshopper vb component?

The only other thing that I can think of in order to assist in Debugging would be to use strategically placed Msgbox functions to display certain values at runtime.

Replies to This Discussion

Permalink Reply by Jon Mirtschin on March 2, 2010 at 6:39am

With Visual Studio, you can debug into very easily. If you are compiling to a dll file (whether it's renamed to a .rhp or anything else), point the start external program reference in the debug settings to the Rhino executable. Then you can set break points etc which will be hit whenever the code is referenced when executed from Rhino (be it from within Grasshopper or not). If you have troubles, repost the problem with where you're seeing problems.

Permalink Reply by Paul N Jeffries on March 2, 2010 at 6:58am

There are currently no real debugging tools in the scripting components themselves. I seem to remember David saying that the scripting components were written by a 3rd party, so I wouldn't hold your breath for any being added.

You could try writing all your scripts in Visual Studio first using the plugin SDK and then paste them into the script component, though this is a bit of a hassle since you'll need to have some way of getting the relevant inputs into the code outside of grasshopper. The SDK should be able to set up a project for you with the right libraries linked - if you need to add others you can do so in the Project Properties -> References tab.

I tend to make do in the scripting component just by using Print() with the variables I'm interested in checking at relevant points - though if you're just starting out you might find you need to do this a bit too frequently to be a useful method.

Permalink Reply by Ben Fortunato on March 2, 2010 at 8:47am

So what you are saying is that I can import all the namespaces etc so I get the type hints and so Visual studio will pick up any syntax mistakes in rhino or ONurbs methods, but there is no way to import or connect the variable comming into the VB component from the larger grasshopper solution. . . . .

Unless their is a way to import lists of points etc from grasshopper then I think using Visual studio is not really helpfull.

Is there a way to grab visual studio via a com connection and then pass the data to it? . . . . It just seems that if you are using the VB component its actually pretty limited. Without debugging tools you have to limit yourself to really simple code, although this can be a challenge for newbies if left working in the dark.

Permalink Reply by Jon Mirtschin on March 2, 2010 at 9:41am

VB and c# components are useful for small scripts and for those users without visual studio installed. Anything slightly complicated I would suggest would be difficult without developing the code in Visual Studio and cutting and pasting the code into a component (if you don't want external dll's to be referenced).

The better means is as you've suggested, add a reference (right click on the vb or c# component and add Reference) and then effectively call a wrapper function. If you have a look at my stadium example referencing my StructDrawRhino plug-in (download files from http://geometrygym.blogspot.com ), this is exactly how this works. It's not exactly COM interop, it's simply referencing external libraries but this is the easiest method I know of to interact between code in Visual Studio and Grasshopper data.

It's easy to demand things like intellisense etc within Grasshopper, but I believe the code for the existing editor is 3rd party already, and it's fantastic that scripting is so readily available (for a long time it wasn't). I'm sure David long term would ideally have aspects such as debugging etc included, but I can't imagine it's a priority (or will happen quickly given the rebuilding taking place).

Hope this helps,

Jon

Permalink Reply by David Rutten on March 2, 2010 at 11:00am

It's indeed not a high priority for Grasshopper, but it actually is somewhat of a priority for Rhino in general. We are expanding the number of scripting languages we support in Rhino5 and Rhino for Mac, and so far we've been using less than ideal editors for all of those.

It would seem that any work done to improve matters would indirectly benefit Grasshopper as well. One of the more promising solutions would be to use the SharpDevelop editor .It's open source, so we could probably rip it out and provide it as a standalone control.

--
David Rutten
david@mcneel.com
Poprad, Slovakia

Permalink Reply by Maxim Broos on April 22, 2014 at 9:11am

Is there any news regarding this topic?

I'm still struggling to find why my code keeps saying Index out of range.

Any debugging tips?

Permalink Reply by David Rutten on April 22, 2014 at 10:22am

Alain Cormier (our newest hire) has been assigned to this project (among other things). So at least it means it's moving forwards. I doubt anything will happen for Rhino5 on this.

If you have to debug in a script component, then I suggest using Print() or RhinoApp.WriteLine() to keep track of variable values. It's a major pain compared to VS debugging, but there you have it.

David Rutten

david@mcneel.com

Permalink Reply by Maxim Broos on April 22, 2014 at 1:21pm

Wow! Thank you very much for this!

At least there is light at the end of the tunnel, we'll be patient!

All the best for Alain, he must be facing one hell of a task!

RSS