Is there any way to ask Grasshopper politely to stop computing without killing it?
Working without glasses resulting involuntary pressing graft 
which push GH into endless process…
I don’t think there is a way to recover without killing it. But it is possible to restart and get really close to where you were.
These are the things I try - one of them has always worked. Note that this is for Windows - I know nothing about Macs or Unix.
- Click the X box on the Rhino window to end Rhino.
- On the task bar, hover over the Rhino button and click it’s X box.
- R-click the task bar and open Task Manager. Find the Rhino task (it will be in the top group), click it, and then click ENd Task button at lower right.
You should get some message about “Do you really want to end Rhino?” Just click yes and it should end. It will take GH with it.
Note that GH will have saved a copy of your latest changes in it’s Autosave directory. Depending on something unknowable to end users the file saved there may or may not contain the problem that caused GH to enter a disabled loop. The good news is whatever is saved there is the most recently updated version of your GH file. So the safest thing to do is restart Rhino & GH, Lock Solver in GH, and then open the most recent file in the Autosave directory. Then look carefully at the GH components and see if the one that caused the loop is there or not.
I know these steps in Windows and I use them, whenever necessary. I only hoped there is some way to avoid the brutality.
Thanks for response.
Certainly this is one of the most time-consuming Grasshopper issues.
It seems to be difficult though, the question’s been asked before, and as far as I know no developer has ever hinted at a fix.
Maybe look around for those glasses. :-}
A fix isn’t really possible while the solutions are calculated on the UI thread, as they are in GH1. This cannot be changed without completely breaking the SDK. It will have to wait fir GH2, whose solutions are both multithreaded without blocking the UI.
1 Like
Thanks David - we love multithreaded code.
You love the concept of multithreaded code, you wouldn’t be so fond if you had to develop for it.
It’s going to be a lot harder doing any sort of UI or non-standard stuff from components in the future.
1 Like
You are precisely correct David. That’s just one reason I’ve given up writing code and left that task to people much smarter than I am. It’s also why I’ve become quite fond of “node programming” in apps like GH and App Inventor.
I’ve become pretty fond of Heteroptera’s Freeze/Gate component. In Gate mode, with the name changed to just “Gate”, it’s the smallest component I’ve found that lets you use an RCP toggle to stop data propagating downstream.
(Why an RCP toggle? Because toggles on the workspace require a double-click but they’re shaky about recognizing it when anything is running. I’d end up clicking several times, toggling on and off without any feedback, triggering the time-consuming operation that I’m trying to halt several times over. Toggles on the RCP take one click and always see it, so off means off.)
In complex models the biggest delay for me is always waiting for the drawing pipeline because you accidentally changed a preview mode incorrectly. It’s almost always a large amount of elements. Having an option to abort the meshing/drawing pipeline would be awesome.
That will suffer from the same problem as cancellation in GH1, in that the screen updates necessarily happen on the UI thread and will thus prevent key and mouse events from being processed.
Rhino itself has some options for degrading the display when a single frame starts taking too long (skip objects, only draw boundingboxes, only draw wires, …) which is a possible solution to this problem. Thoughts?
This sounds like an awesome alternative that would work just as well.