Hi there @stevebaer, @scottd, and @kike!! It has been a few moments since we covered this topic at the last TT AEC, but I finally got around to trying to automate silent loading of a GH script with a HumanUI using the methods we talked about. Will document my attempts here and I’m hoping we can get something to work so people can build slick apps on top of Rhino/GH with killer UX.
So… I’ve been playing around with the Rhinoscript interface for Grasshopper and it looks like so far my hopes have been dashed on what I’d like to accomplish. To recap, here is the goal:
- Create a Rhino Plugin that contains 1 command, which can be run via command line or via a button in an RUI toolbar
- The command launches Grasshopper (with absolutely no visible evidence of Grasshopper) and opens a Grasshopper script with a HumanUI interface (again, without triggering any visible instance of Grasshopper)
- The script nonetheless executes when operating the HumanUI (this is the hard part, as we will see), despite there being no GH window
I’ve been using the API doc methods here:
I’ve noticed several problems with the methods in the API, with respect to what I’d like to accomplish:
- DisableBanner(): This is great and a welcome method – however, I would like to also be able to enable silent loading (no echo in the Rhino Command Line). Even better (amazing, actually) would be providing an overload that would allow me to define my own custom splash screen (Waaaaaaat!)
- LoadEditor(): Again, love that the Load function is separate from the Show function, and simple tests show that it is possible o “Load” grasshopper without the window appearing. However, the behavior of other methods crushes the hopes and dreams that I had when looking at the documentation
- OpenDocument(): And here’s where the tears start to flow. From the API docs: “Open a Grasshopper document. The editor will be loaded if necessary, but it will not be automatically shown.” Well in my case, using this method on a script that I have built with full HumanUI (no GH interaction necessary), regardless of whether I call LoadEditor() first, it does indeed automatically show the editor.
- HideEditor(): There’s hope still! Perhaps if I hide the editor first, before opening the document! Nope, disappointment ensues. Okay, so maybe I’m disappointed that the Editor does in fact show during the load process, but I do have a script within my GH definition that automatically minimizes the editor so it’s not blocking my UI. At least I can use HideEditor() to get rid of that pesky GH window minimized at the bottom of the Rhino UI, right? A flicker of joy, as I successfully hide the GH window entirely – “this is it!!!” I think, and then deep sadness sets in as I push a button and nothing happens, as it appears that when the GH editor is hidden, it no longer functions (at least with my intensely insane script)
- EnableSolver(): Perhaps I can enable the solver on a hidden GH instance! Nope.
Anyway, just thought I would do a dramatic retelling of my last 20 minutes for fun. H’s a sample of the code I’m using so you can point out any stupid mistakes I’m making:
dynamic gh = RhinoApp.GetPlugInObject("Grasshopper"); gh.DisableBanner(); gh.LoadEditor(); gh.HideEditor(); gh.OpenDocument(appGhFilePath); //gh.HideEditor();
Tried various combinations and orderings here. Main fixes would seem to include:
- HideEditor(): Not disabling the GH execution context in this state (easier said than done?)
- OpenDocument(): overload with a flag to prevent editor from showing automatically, or fixing the bug that does force it to show, or document in which cases it will automatically show, etc – also good compromise would be the ability to load in minimized state (never seeing the full GH window), a function not currently provided by the API (and would get me almost all the way to my goal)
- DisableBanner(): overload that allows silent load (no Rhino command line echo)