Close GH Player definition

Grasshopper
23

Ive just made a video going over this work flow setup - details here:

2 Likes
24

Adding this thread to the “Please can we have a tidy way to close compiled GH scripts” ongoing request:

Cheers

DK

1 Like
25

Can you use Grasshopper.Instances.DocumentServer.RemoveAllDocuments() Not sure how whether it actually handles everything in the background properly. I at least see that the UI windows of DKUI/SYNAPSE/HUMANUI stays, but they GH file is brutally closed.

26

Hi @Timo_Harboe_Nielsen

As discussed offline, I’ve tested the API call you suggested. Like all similar approaches, it works as expected when the definition is open in the GH canvas — but does nothing once compiled or executed via GH Player in headless mode.

At this point, I’d like to formally request that McNeel provide a supported method — via RhinoCommon or the Grasshopper API — to close a GH document in compiled/headless mode. This is a critical missing piece that’s preventing a clean, autonomous plugin workflow using Grasshopper.

To be candid, it’s hard not to feel like GH based Rhino Plug-in development is being treated as a second-class workflow. Despite the existence of the DKUI (and similar UI tools), Script Compiler, GH Player, and Yak — all suggesting GH development is viable for serious plugins — there are still key limitations like this that make it feel like C# remains the only “supported” way to build Rhino plugins.

Grasshopper offers an incredible environment for rapid, maintainable, and visual plugin development. But unless gaps like this are addressed, it’s hard to justify continued investment in GH-first workflows for complex tools.

If there’s a technical reason this hasn’t been solved, I’d really appreciate insight — or even a recommended workaround from the dev team. Otherwise, I hope this can be prioritized in future updates.

Thanks again,
DK

2 Likes
27

@eirannejad would this be something you would be looking at? Or @AndyPayne is this still your domain?

I have a been thinking about a spec for what this component/code might look like, based on the behavior of the context number input workflow above.

When I get some time I’ll write it out.

Cheers

DK

28

YES! This feature is desperately needed!

30

I’ve created a YT issue (RH-89265) to track this issue.

31

Thank @AndyPayne

Here are my notes on what this might look like:

Developer Spec: Context Close Component
Author: David Kay (DK)
Target: Grasshopper Player & Script Editor–compiled scripts
Purpose: Enable controlled, programmatic closure of GH definitions.

Component Purpose / Behavior

  • Hold open a GH definition while waiting for a Boolean trigger.

  • Close the definition cleanly when the Boolean input becomes True.

Rationale / Motivation

Currently, Grasshopper Player and compiled GH-based plugin execution is rigid and binary:

  1. Keep Open Checked – the definition stays alive indefinitely; no programmatic closure is possible.

  2. No Context Inputs, Keep Open Unchecked – the definition runs once and exits immediately.

  3. Context Input Components Present (e.g., Number, Text, etc.), Keep Open Unchecked – the definition stays open until the last context input is entered.

    • Developers often rely on magic values (e.g., 222) as triggers, requiring manual input into the Rhino command line.

    • This approach is fragile, unintuitive, and blocks Rhino canvas selection, limiting plugin functionality.

There is currently no supported way to:

“Hold a GH definition open temporarily for interaction or processing, then close it automatically when a programmatic Boolean condition is met.”

Desired Outcome

  • Enable a clean, programmatic mechanism to keep the definition alive until a Boolean signal triggers closure.

  • Allow UI-driven or headless workflows (e.g., DKUI, Human UI) to exit gracefully without leaving residual GH documents or blocking Rhino interaction.

Implementation Note

  • This component could be based on the existing context input code, as it already provides the “hold open” behavior.

  • The main addition would be listening for a Boolean input from the GH canvas to trigger clean closure.

    • It must not block any behavior on the Rhino canvas while waiting.

  • This would make the behavior fully programmatic, eliminating the need for manual input or magic-number workarounds.

Please let me know if this is helpful and if there was anything else I could add.

Cheers

DK

3 Likes
Grasshopper Player in compiled plugin issue
32

Thanks. This is helpful.

34

I’m also eagerly awaiting this issue to be resolved, because every time I come back to this topic, I’m dealing with terrible workarounds… I saw some activity from @eirannejad in another thread, so I hope we can resolve this issue soon.

In the meantime, here’s a little code that can be attached to a button. It will send “T” or whatever you set to Rhino Command Line, so you can exit the GH Player without typing the magic number :slight_smile: , but by pressing the button in the GUI.

(In GH Document Properties, “Keep open after command completes” must be set to OFF, otherwise you’ll get the entire Grasshopper Breakpoint series—this is for those who are just stumbling upon this issue and don’t know all the tricks yet.)

// Grasshopper Script Instance
#region Usings
using System;
using System.Linq;
using System.Collections;
using System.Collections.Generic;
using System.Drawing;

using Rhino;
using Rhino.Geometry;

using Grasshopper;
using Grasshopper.Kernel;
using Grasshopper.Kernel.Data;
using Grasshopper.Kernel.Types;
#endregion

public class Script_Instance : GH_ScriptInstance
{
    private static bool _prevSend = false;

    private void RunScript(bool Send, ref object Msg)
    {
        if (Send && !_prevSend)
            RhinoApp.SendKeystrokes("T", true);

        _prevSend = Send;
        Msg = null;
    }
}
35

RH-90408 is fixed in Rhino 8 Service Release 27