Grasshopper

algorithmic modeling for Rhino

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

Views: 940

Replies to This Discussion

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.
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.
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
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.
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.

C#
//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)
so nice, thank your for your solution
why is the referenced assemby not on a global scale but only in a local vb node. this makes things more difficult.
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.
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.
are functions within a .dll faster than the script?
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.
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

RSS

About

Translate

Search

Photos

  • Add Photos
  • View All

Videos

  • Add Videos
  • View All

© 2024   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service