transfer custom objects and access them in another VB component

Good morning everyone,
again one little question regarding grasshopper vb scripting.
is it possible to transfer custom Classes to another VB script component input
and access the Methods and functions? do i have to implent it in the rma.opennurbs?
Is it possible to have a custom declaration region for alls vb scripts?

with best regards

Michael Sprinzl

ok i solved the problem....
to build your own custom objects which can be communicating between different VB components:

1. build a classlibary in vb.net like this:

Public Class FEM_element
' Fields
Public Material As Integer
Public Element_nummer As Integer
'Methods
Public Sub New(ByVal i_Material As Integer, ByVal i_Element_nummer As Integer)
Material = i_Material
Element_nummer = i_Element_nummer
End Sub

and save it to the Grasshopperplugin folder!!! as xxx.dll dammm it took me 2 hours to find out.

2. Put 2 VB components on the Grasshopper gui
and attach the xxx.dll with the Referenced Assemblies tool

3. vb component 1:

Dim aa As New FEM_element
aa.Element_nummer = 1122
aa.Material = 12
a = aa
End Sub

vb component 2:

Dim aa As New FEM_element
aa = x
print(aa.Element_nummer)
print (aa.Material)

4. finito bandito .... you now have your own custom type connections ....lol

Replies to This Discussion

Permalink Reply by Rajaa Issa on June 7, 2009 at 2:05pm

Hi Michael,

Yes, this is how you may do it at the moment. In the furture, you will be able to extend Grasshopper to define your own custom types. This wil take some time to happen though.

Permalink Reply by michael sprinzl on June 8, 2009 at 11:55am

Hi Rajaa,
i still have some difficulty wirh implementing the opennubs library with in windows vb.net.
this would spped up the programming of the coustom types.

Permalink Reply by kyle steinfeld on August 18, 2009 at 3:23pm

Michael, Rajaa,
No go for me, I seem to be having a casting problem and get the following error:
Script exception: Unable to cast object of type 'Grasshopper.Kernel.Types.EH_ObjectWrapper' to type 'PrattGrasshopperUtil.pPanel'.

tried explicit casting as well, both DirectCast and CType... no go.
any thoughts? I'm using 0.6.0018

Permalink Reply by shawn on October 6, 2009 at 9:22am

Hi Kyle,
Were you able to resolve this casting problem? I am getting the same error and am using 0.6.0019 build of GH.

Permalink Reply by Giulio Piacentino on November 10, 2009 at 1:56am

Hi shawn,
when you pass your own types of object in Grasshopper, they will be wrapped automatically. The two following examples show how to get the value inside the wrapper.



//This is our object

SomeObject someObj = new SomeObject();



//Grasshopper automatically wraps it

Grasshopper.Kernel.Types.EH_ObjectWrapper ow = new Grasshopper.Kernel.Types.EH_ObjectWrapper(someObj);



//You can get the value from the wrapper and cast it to the original value

SomeObject gettingObj = (SomeObject)ow.Value;

VB.NET



'This is our object

Dim someObj As New SomeObject()



'Grasshopper automatically wraps it

Dim ow As New Grasshopper.Kernel.Types.EH_ObjectWrapper(someObj)



'You can get the value from the wrapper and cast it to the original value

Dim gettingObj As SomeObject = DirectCast(ow.Value, SomeObject)

Permalink Reply by wangbin on June 7, 2009 at 7:57pm

so nice, thank your for your solution

Permalink Reply by michael sprinzl on June 8, 2009 at 12:14am

why is the referenced assemby not on a global scale but only in a local vb node. this makes things more difficult.

Permalink Reply by Rajaa Issa on June 8, 2009 at 2:45pm

Hi Michael,

You can think of each vb node as an independent class that get compiled on the fly. This is why your referenced libraries are local to each node. If you need multiple components to reference your library, then you will need to compile your components using GH SDK and some development environment (visual studio). Exposing GH SDK is still to come.

It maybe possible to add a component that import user-libraries and would be automatically included in default scripting component. We'll have to wait for David to answer that.

Permalink Reply by michael sprinzl on June 11, 2009 at 8:08pm

actually it worked, I linked the opennurbs.dll and the rhinodot .net something from the systemfolder of rhino3d and i had the libarys within the Microsoft visual basic. I think it did not work previous before because of the versions of the vb.net sdk. So you do not need the grasshopper sdk.

Permalink Reply by michael sprinzl on June 11, 2009 at 8:10pm

are functions within a .dll faster than the script?

Permalink Reply by Damien Alomar on June 11, 2009 at 10:35pm

If they are compiled, that I would say yes, but since GH scripts are, in general, fairly lite, I wouldn't imagine that there would be a significant difference. In order for the dotNET framework to actually do anything with any code, it has to be compiled into CIL (common intermdiate language) code, which is what the dotNET framework actually uses to create the instructions for the OS. Creating a DLL does performs this step, but with uncompiled code, it must be interpreted into CIL code before the dotNET framework can actually do anything with it.

Permalink Reply by David Rutten on October 6, 2009 at 10:47am

Indeed. DotNET dlls are generally slower to load than old-skool C++ dlls, because DotNET code is only "half-baked" as it were.

The instructions inside a DotNET dll are not machine code instructions, they are instead a binary version of the source code written in a language called MSIL (MicroSoft Intermediate Language, sometimes also called IL or CIL as Damien mentioned).

When you run functions inside the dlls, they have to be compiled into actual machine code instructions first. This happens only once, and it only happens at the very last possible moment (i.e. it is "lazy"), but it does take a little bit of time.

However, once your DotNET code has been compiled from MSIL into machine code instructions, there is absolutely no reason it would run any slower than any other code on the market. In fact, since DotNET code is always compiled on the client machine rather than the developer machine, they can actually specifically target your CPU type which means more effective code.

--
David Rutten
david@mcneel.com
Seattle, WA