Is it possible to call the functions of a Grasshopper component from inside a (C#/VB.Net/Python) script? - Grasshopper2024-03-28T21:06:15Zhttps://www.grasshopper3d.com/forum/topics/is-it-possible-to-call-the-functions-of-a-grasshopper-component?feed=yes&xn_auth=noOk, two answers to the above:…tag:www.grasshopper3d.com,2015-12-18:2985220:Comment:14234242015-12-18T12:26:20.055ZJames Ramsdenhttps://www.grasshopper3d.com/profile/JamesRamsden
<p>Ok, two answers to the above:</p>
<p>1) If you are accessing a Grasshopper component written in the usual way (i.e. most of the logic is contained within the SolveInstance) then the methods talked about above are the closest we seem to be able to get to remotely accessing the component. It's ultimately dependend upon a GrasshopperDocument.</p>
<p>2) If you are creating your own components, you can plan in advance when writing your component to make it more easily accessed remotely later. My…</p>
<p>Ok, two answers to the above:</p>
<p>1) If you are accessing a Grasshopper component written in the usual way (i.e. most of the logic is contained within the SolveInstance) then the methods talked about above are the closest we seem to be able to get to remotely accessing the component. It's ultimately dependend upon a GrasshopperDocument.</p>
<p>2) If you are creating your own components, you can plan in advance when writing your component to make it more easily accessed remotely later. My colleague Fraser wrote about it here: <a href="http://frasergreenroyd.com/how-should-you-be-coding-grasshopper-components/" target="_blank">http://frasergreenroyd.com/how-should-you-be-coding-grasshopper-components/</a></p> Well-written code separates t…tag:www.grasshopper3d.com,2015-12-09:2985220:Comment:14184652015-12-09T23:12:54.878ZJames Ramsdenhttps://www.grasshopper3d.com/profile/JamesRamsden
<p>Well-written code separates the interface from the logic. If all GH devs (myself included!) remembered to do this, then accessing this logic would be relatively simple. But the way that GH works, and the way that the GH_Component class is set out, it encourages a 'scripting' style of programming where the core logic tends to end up directly in the SolveInstance method. And since this method ties into the Param Manager for getting data in and out of the SolveInstance, which itself seems to…</p>
<p>Well-written code separates the interface from the logic. If all GH devs (myself included!) remembered to do this, then accessing this logic would be relatively simple. But the way that GH works, and the way that the GH_Component class is set out, it encourages a 'scripting' style of programming where the core logic tends to end up directly in the SolveInstance method. And since this method ties into the Param Manager for getting data in and out of the SolveInstance, which itself seems to depend upon a GH_Document to work, it all starts getting rather messy rather quickly. So yes, it would be a lot easier to use a separate library, but odds are if you're trying to use someone else's component programatically, they likely haven't done this.</p> Thanks for sharing, Andrew. I…tag:www.grasshopper3d.com,2015-12-09:2985220:Comment:14182882015-12-09T23:02:28.241ZJames Ramsdenhttps://www.grasshopper3d.com/profile/JamesRamsden
<p>Thanks for sharing, Andrew. I have yet to actually find a practical application for this technique. As you say, most components can have their behaviours replicated with RhinoCommon methods. (Internally, this is what the components themselves are doing anyway - so instantiating the component around the method is just baggage.) I just thought it was cool that components can be programatically operated at all!</p>
<p>What would be amazing is if we could use the logic of Grasshopper components…</p>
<p>Thanks for sharing, Andrew. I have yet to actually find a practical application for this technique. As you say, most components can have their behaviours replicated with RhinoCommon methods. (Internally, this is what the components themselves are doing anyway - so instantiating the component around the method is just baggage.) I just thought it was cool that components can be programatically operated at all!</p>
<p>What would be amazing is if we could use the logic of Grasshopper components without needing an instance of Grasshopper running. Some of the components I've been writing recently have quite substantial environmental engineering calculations that would be useful outside of GH as well as in it. After all, a GHA file is just a DLL, and the logic can be found as methods within, like any other DLL. We've made some progress in decoupling the file from GH for this purpose. I'm going to try and dig out some code when I'm back in the office tomorrow.</p> Would not it be easier to mak…tag:www.grasshopper3d.com,2015-12-09:2985220:Comment:14181832015-12-09T19:40:46.947ZDaniel González Abaldehttps://www.grasshopper3d.com/profile/DaniAbalde
<p>Would not it be easier to make a separate library to use components from script without the shell of gh_component? I'm doing that for Peacock. And I wish it to grasshopper because its components are quite generalist and robust, in some cases it is advisable done from RhinoCommon but in others we would save much much time...<br/>I'd love to see what David has thought about it for GH2! :3</p>
<p>Thanks for the post Andrew, very interesting!</p>
<p>Would not it be easier to make a separate library to use components from script without the shell of gh_component? I'm doing that for Peacock. And I wish it to grasshopper because its components are quite generalist and robust, in some cases it is advisable done from RhinoCommon but in others we would save much much time...<br/>I'd love to see what David has thought about it for GH2! :3</p>
<p>Thanks for the post Andrew, very interesting!</p>