Grasshopper Window Minimize/Maximize Behavior -- request improvements

I build a lot of custom tools with Human UI so that users can work with an “application”-style experience without needing to know or understand grasshopper (or even know that it exists).

I’ve noticed that the minimize/maximize behavior seems to have changed recently in Rhino 6. Notably that when Grasshopper is minimized, and then the user minimizes Rhino and unminimizes (via Windows taskbar), then Grasshopper automatically unminimizes (instead of remembering its minimized status). See attached. This is a major UX issue for my application users because they are confronted with an alien window that they don’t understand when unminimizing Rhino.

I understand that other users may love this new UX. However, can there be an application setting that I can control via RhinoCommon to disable this “feature”? I would be happy to write my own document listener that can set this setting depending on the Grasshopper document context.

Finally, one step better for me would be able to hide Grasshopper entirely (so that it does not appear at all when minimized – this behavior could be reset by running the Grasshopper command in Rhino), or to be able to set its behavior to “Appear in Taskbar” so that when minimized it has its own tab (preferably with a GH icon). The reason is that I use my own WPF menus that can minimize to small minwindows and they get stacked up against the Grasshopper window, and it would be great to have them super clean and uncluttered.



Any thoughts on this @dale or others?

Hi! …i’m not dale, sorry to barge in…

02:00 am madness here!
WARNING: i’m a complete noob/rookie about everything i’ve used here.
I still miss ALL the c# basic teachings…
I’ve took blocks of codes around and mashed them togheter… i surely have NO idea how/why/when this works.
So I’m not responsible on whatever this will cause and please double… triple-check to have your own safety by using this foreign code!! (it’s not mine, I didn’t read it at all! … might contain… anything! … and c# actually have FULL access to your machine…) (9.3 KB)

The first c# script uses code by jiverson from:
It find the “handle” of a window with name/title starting with “Grasshopper -”
As this is probably heavy, i put it on a separate script, so it will run just once.

The second c# script uses code by Nicolas Tyler from:
It minimize/maximize/restore a window from a given handle.

I’ve added a boolean to “Keep active” this second script (aka expiring and restarting itself over and over)
So whenever rhino would restore the gh windows, shortly after the script will set it again to the vanted state.

Do “Publish to remote panel” to the Minimize boolean, so you can retrieve your window.
If you set Keep_active=true and then minimize=true without remote panel you won’t be able to restore gh window anymore… you’ll need to force close rhino/gh and re-open it with disabled solver…

Hope it helps…

(The .gif file is 300+ times larger than the .gh definition here… just LOL)

Interesting – not exactly what I’m looking for, but in the neighborhood. Would love a native GH solution, but something like this could work in desperate times. I’ll take a look!

As you showed here Possible to have a rhino button minimize the grasshopper window?
I’ve re-made the script.
It’s so much simpler now… shame on me!


private void RunScript(bool Minimize, bool Keep_active)
    if(Minimize) Grasshopper.Instances.DocumentEditor.WindowState = System.Windows.Forms.FormWindowState.Minimized;
    else Grasshopper.Instances.DocumentEditor.WindowState = System.Windows.Forms.FormWindowState.Normal;
    if(Keep_active) this.Component.ExpireSolution(true);
  } (4.2 KB)

Same “rules” as previous version… but way lighter and simpler…


I never looked at the code to see what you were doing – but just an FYI, this is a nuclear option to keep the window minimized and should never be used in production, imo.

You are creating an infinite loop by calling this.Component.ExpireSolution(true) – a better solution that would not carpet-bomb the canvas repeatedly would be to attach an event handler to the Grasshopper window to trigger a single execution when and only when the GH window unminimizes. I’ll probably end up having to code this but at the moment it’s pretty low on my priorities. I’ll post the solution if I end up having to implement it.

Note: I consider this a workaround and was trying to avoid doing this – the intent of the original question was whether McNeel could add a configuration option that would allow me to set the GH window behaviour to not automatically unminimize Grasshopper, rather to remember its state. That, to me, is much cleaner and requires one less window listener. I’ve got enough listeners. :slight_smile:


Recently I found a better solution using the Grasshopper.Instances.DocumentEditor.Activated event and Grasshopper.Instances.DocumentEditorFadeIn / …FadeOut methods.
Works pretty consistently and as a bonus hides the GH completely, instead of collapsing it into the minimized bar in bottom left corner.

Since some recent update, the original script stopped working reliably. I added couple of lines to make sure it still works as intended, but it was a sort of a quick hack, so the code could still be probably cleaner. Feel free to experiment with it.

Updated example file: (2.5 KB)


many thanks

Thank you for this definition. It is working for me but only if the Grasshopper window it is in the main display. As soon as I do move the GH window to the second monitor it stops working. Do you know any fix for this issue?