Is it possible to access the "scriptcontext.sticky" of the Grasshopper Python component via C#?

Hello everyone,

I am pretty new to Python (and IronPython) and very curious to know if it is possible to access “scriptcontext.sticky” via C#?

Can someone please tell me how I can use IronPython objects in C# to interact with Python objects in Grasshopper (like PythonModule or PythonDictionary)? I mean, is there any optimal way to convert the IronPython objects - even custom objects - into the C# objects?
Can someone leave a link to a good tutorial please?
I appreciate your help in advance. :blush:

I don’t think you can access it, it’s a different language. But you can translate it.

The equivalent of the python modules would be the .dll libraries in C# ?, which you can create by compiling C# scripts in Visual Studio. For a dictionary, you can use:

Thank you Dani, I’ve updated the topic’s text.

I’m fairly familiar with C#, but I’m looking for an efficient way to use IronPython objects in order to extract the information hidden in outputs of Python components, into the .NET environment. Because I find development in the .NET environment much more manageable and transparent!
(I am also looking forward to receiving feedback about this opinion! :grinning:)

I think the information must be available in Grasshopper. The question is how to access this information via C#! :thinking:
What do mean by translation?

I don’t understand, I don’t know Python. If you only want the output data, what does python have to do with it? python’s scripting component is no different from the rest. Just iterate through the component’s output parameters and get the data, right? Or do I miss something particular about python?

Maybe by System.Reflection or dynamic?

1 Like

Could you please provide more information or explain your idea? :slightly_smiling_face:

Hi @gankeyu ,
I am also interested in the same issue. Do you by chances have a short example of how we can replicate the sticky dictionary in C#?

Hi Djordje,

Both, the Python and C# script components are lacking a central place to store “global” variables. This is because both script-components are living within an encapsulated namespace. Once it’s compiled, the code is difficult to access from outside because the namespace of the dynamically added code has a cryptic unique name (something like ScriptComponent_3jk243k432l4m234l23m4l234m). Therefore, a global register like sticky comes in handy. But it remains a hack. Another hack would be to inject data to a fixed location on existing objects. I think you can make use of so-called extension methods. In any case, you are breaking encapsulation, so it’s in my opinion bad in any regard.

From a C# plugin, there is no need for such a dictionary. You are free to create any namespace, so as soon as you add ‘public static’ keyword in front of your class member, you can access that element from anywhere you like without instantiating. A ‘better’ solution is to implement a (thread-safe) singleton class, because then you only deal with one global variable.

For scripts, I’m pretty sure you can access sticky. Working with either the dynamic keyword or by casting to the correct type, you should be able to modify it, but I’ve never done this.

1 Like

Thank you for the detailed explanation Tom.
Sorry if I was not precise enough: I didn’t mention that I needed it for scripts.

Is there some online example by chance?

If someone stumbles on the same question, I ended up creating a dictionary as a class variable. Thus resulting in all class instances having access to this dictionary.
Then compiled such class to a .dll.

There is a dictionary on the RhinoDoc called RuntimeData that is very similar to sticky that you could use as well.

1 Like

Thank you Steve.