The underlying issue in this thread — and the one I linked above (as well as others) — is that right now there are only two options when it comes to the behavior of compiled Grasshopper scripts:
1. Run once and exit
This does not work when you have a user interface (HumanUI, Synapse, DKUI, etc.) for the user to interact with — because as soon as the script runs once, the GH document is closed, and the UI has nothing left to talk to.
2. Check the “Keep open after command completes” button
Now your command/plugin with a full UI works… but your GH definition can never be closed. It becomes a zombie. Not one of the 3 or 4 available GH API calls that are supposed to close a GH document can put a bullet in the head of a compiled GH def once it’s running in this mode.
Both of these options miss the mark on what myself — and others — have been asking for:
We want to be able to control this behavior from our own code — stay open when we need it, close and clean up when we’re done.
This whole thread is about a side-hack that sort of gets us there.
Fix the underlying issue, and this thread (and others like it) are solved at the same time.
@eirannejad we - the compiled GH, Rhino plugin developers of the world - request that this^ behavior be supplied to us as a either a GH component OR at the very least a Rhino/GH API call.
We all have zombies - we want to put a bullet in their head - PLEASE, give us the gun to do it.
Yes, I consider that a sort of workaround as well. Of course a better way of controlling how and when compiled scripts using the Player end their execution (as you are suggesting) would be very welcome.
HI @eirannejad, it’s been a month, any news on this front? Or has the discussion moved to another topic? After all, as @kiteboardshaper pointed out, the main issue is a better way to control how and when the scripts close when used with the player…
I was talking to another DKUI user today who asked how to close their script within the current Rhino session.
The reaction was absolute shock when I had to explain that McNeel still provides no way at all to close a Grasshopper definition once “Keep open” is checked.
I can’t overstate how immensely frustrating this limitation is for those of us building compiled, UI-based Grasshopper tools for clients. Many of these tools represent software worth many times the cost of a Rhino license per seat, yet we’re unable to provide something as basic as a controlled shutdown or “close” system.
Are we to understand that — simply because we develop in Grasshopper rather than C# — our work is considered second class within the Rhino development ecosystem?
Please, could someone at McNeel take another look at this one, small but critical issue? It would make a world of difference to a lot of us developing professional-grade tools on top of Grasshopper.
I will post an update soon