This is basically a continuation of a question I asked about global variables.
Is it possible instead of using sticky and data input/output components to somehow access variables set in some scripting component on the canvas?
Also, where should I place these variables to make them global for GH, not just for that particular component where they were defined.
Well, I’d keep the variable in… a parameter (or script component) and connect to it with wires, as usual,. 
The variable (see above) can be stored on disk and retreived from a disk file again using the Data Output and Data Input.
// Rolf
Thanks for the reply Rolf.
Yeah, I know about the data input and output components, as well as the sticky, but in some cases you want a global variable to be set. One that you can use and modify from many scripting components.
Since there’s no component to set global variables perhaps there is a way doing that through scripting.
Storing values outside of the definitions would make them depending on your machine. Storing data in different definitions may not be optimal either, but at least such definitions can be moved along with the definitions (file is always a file and thus movable) using them (just like any data on disk).
The worst thinkable alternative, though, would be to stora variables in the GH application itself. Why would you like to do that? But if you still would like to do anything such “machine dependent”, then you can store values in the Windows Registry.
Edit: http://www.ironpython.info/index.php?title=The_Registry
// Rolf
No, you’re missing the point. Not storing them inside grasshopper, but creating and using the global variables within the file, thus them being movable with the gh file and not Machine-dependent.
Upon running the gh file the globals are created first, then all other components are able to use them. Much like using ghdata files only them being created in the memory instead and calculated without the 1 second delay but rather as soon as all canvas calculations are done. I don’t really know when they can be executed as I don’t know GH’s code.
I don’t know the difference between using sticky and ghdata files. Are both of them Dictionaries?
One thing I know, these global variables need to be updated regularly it’s just pointless having them static.
I guess another option would be running a different app alongside GH, in a separate thread to create these in the memory. However I don’t know how stable could that be or how can I access them then. Perhaps this is how stickies are created behind the scenes, I don’t know.
Why not make a “globals” script component then, and connect it to whatever components using the info?
// Rolf
Yes, this is one of the options I’m working on right now. Idealy I wanted to avoid having to connect with wires, because I’ll have thousands of these components, in the final version of my project, cross referencing each other. This is why I started reducing the number of components.
First it was with data input/output, then I moved to sticky where the amount of components increased but I ditched the wires. Unfortunately introduced the need for the Timer component.
Then I tried to implement it all in one component but some showstopper issues appeared. Here’s the thread about that:
Going wireless in a flowbased network is… well, like skipping the car when going for a road trip and flying along the road instead. 
// Rolf
Worth the try 
, You can find components on the canvas, why not access what’s inside them.
Currently I try to create global stickys sending their labels to “Panel”, so I get a list of their labels.
Then I can find that Panel get the list and use the labels to assign values to the global stickies. At least that’s the idea, still not working, though 
.
If you wonder why would I make a list of sticky labels: I placed a button to generate new guids that I attach to the labels to make them unique.
Regarding the “too many wires” problem, I can give you a hint relative to the picture you sent earlier.
You can divide all the “Bulb settings” into a single input, and use your own class to input that as a single input. Make sure your input classes are immutable, and it will behave just great.
Then do the same for “Parallel Midship settings”… etc. Group them into settings/info/modes (like “Custom Mesh settings” works for inputting settings with sliders in “Mesh Brep”).
That’s how a relatively simple way to keep wires in check and use the way Grasshopper is supposed to work.
Does it help? 
Perhaps this:
Will help more, if I drink alcohol.
This topic is related to this one:
And not to the pictures I’ve sent to you over PM, which should stay in PM.
Now concerning this:
I learnt how to create custom types, but afterwards how can I get the data from them still avoids me. i.e. from goo to get the 3d object for example. But that’s a topic for a new thread (from the hundred yet to be created).
I wonder if Karamba guys got the same answers from McNeel when they were developing their very appealing and useful customization to their components? Btw I’ve read some of the threads on the old forums and McNeel were very helpful customizing how components look. Tasting the double standard, or perhaps over the years attitude towards customers changed? There were examples, a lot of them. The problem for them not being helpful to me is that they are in VB or Csharp. Especially VB is simply unreadable to me.
So, perhaps it really isn’t the “attitudes” that is the problem then?
// Rolf
oh no, it’s the attitude, as instead of helpful examples I get ignoring and discouraging comments.
IronPython is supported to the core right now. Should csharp “native speakers” get python examples, like I have to work with csharp exampels?
Only a couple of months ago I had never written a line of C# code. And the people who had solutions spoke C#. I didn’t think that they showed “attitude”, instead I learned C#, because that was the way to go for what I was trying to do.
IronPython has its application, and users tend go only so far using it. Which means that the trickiest stuff is done with VB or more likely, with C#. And that’s the language where most of the experience of the more advanced tricks is.
It’s as simple as that.
// Rolf
Something must be cleared out, I don’t put negative meaning to the word “attitude”. I’m not talking about “bad attitude” them being rude or something. They just deflect. Also I don’t say they deflect all my questions, just the ones regarding change of component gui.
I wouldn’t mind learning csharp, I already have some simple applications done with it. I mind having to spend the time to learn all the necessary assemblies and links and calls all over again with the unfamiliar APIs. I don’t work with Rhino, the time I spend with Rhino/GH is after work when I have time. By not getting python examples, which is very readable to me and I use it at work (not IronPython but still similar syntax), I have to spend weeks of my limited free time to figure out how to translate it to python. Over half of my tries end up failed.
The need to declare every single stupid thing with the type is too non-pragmatic. A waste of time and effort.
That’s one reason to not translate it to Python.
I spent some thirty of my best years on Delphi Pascal. I couldn’t read any other syntax. A couple of month ago I thought C# looked like… I had nothing to liken it with. 
And everything new you learn about RhinoCommon/GH can then be foused on C# (which was the stage in which I thought I might as well adopt C# and go right at it). And that will get you faster to where you want (just leave out the translations to Python and you will save a lot of time…)
C# took me some 2 or 3 weeks to get used to (It became “readable” much sooner than I had expected). And I’m not in my twenties anymore. 
// Rolf
Types isn’t a big thing at all. You are forced to use the types in Rhino/GH which you also will use in C#. And BTW, I don’t understand why many people declare types twice on the same row. It looks strange to me as well. Why write like this:
List<Point3d> pointcloud = new List<Point3d>();
… when you can write like so and still explicitly declare the type:
var pointcloud = new List<Point3d>();
The compiler can still “guess” the type, no need to repeat it on the same line. You’ll get used to it, don’t worry.
// Rolf
And I’m absolutely sure, if Pascal was supported as Python is, you’d bang your head asking for Pascal examples.
There aren’t many languages that I cannot read (except for VB and ASM probably, I tried learning ASM some 20 years ago during my wanna-be-a-hacker phase ). What the hell hit in the head the developer of VB for him to come up declaring variables with dim?
Anyways, reading is one thing, writing the code is much different. Good luck with csharp.
The other thing that infuriates me is…Python was supported since, v4 if I’m not mistaken. Why still deflect python questions?
Karamba3d and Solemma are clear examples how “in-component” controls drive true creativity. But no!
Why not just remove that from the API?
If it’s possible to change it, please give working examples in all languages RH/GH support.
There’s an example here: Setting type hints in a Python component - #5 by piac. This is really the way classes should be used in Python and Grasshopper, and it’s really straightforward.
We are not deflecting pure questions. There’s a difference between a “question” and a “demand of custom development”. The guys of the other mentioned add-ons decided to pursue roads of heavy GUI change of Grasshopper. They did it on their own with the public tools provided by our SDK, and we did not provide them with additional tools and they did not start “hundreds” of threads. They were simply experienced enough and did it. Some of these changes were unnecessary and are unrelated from the geometry of the add-on itself, for example I find Millipede too different. Now, I believe you will get experienced enough one day, to be able to define your own GUI and, if you want, basically re-write Grasshopper from scratch. But right now, you should really focus on getting the “primer” part working, because every big task needs its steps and “Rome wasn’t built in a day”.
Python is not suggested for GUI change. As already mentioned earlier, you will need C# for that.
Finally, I am on vacation from today till September, so the rate of my replies will diminish. Alain and Steve will be here.
But feasible.
All I want is simple in-component gui capsule (button) example with python, that will give me the directions where to look for more advanced stuff.