due to some automation task I’m often restarting Rhino and Grasshopper from a script using
/nosplash /runscript=“-grasshopper editor load document open file.gh _enter file.3dm”
Everything works okay so far. Though I do receive Grasshopper error messages (GH breakpoints etc) sometimes that I just can’t resolve. So they’re ignored and if Grasshopper becomes unresponsive, a background host application force quits and restarts Rhino and Grasshopper.
However, I wonder if there is a setting to rudely and forcefully inhibit Grasshopper error messages and warnings?
Specifically the “Potential Plugin Crash Protection” warning upon startup blocks my Grasshopper from being reloaded
Further there are the mentioned Grasshopper breakpoint messages, that I’d like to not receive, but that’s not soo important, as I can just keep ignoring those:
I could think of various hacks to bypass this. For instance you can observe for windows poping up using user32.dll to close them automated. Another option is overriding default behaviour . At least Grasshopper is fully decompilable and therefore quite vulnerable for code injection/replacement.
This however is the wrong end to approach such problem in my oppinion. Actually catching errors on a superficial level is a good thing and shouldn’t be eliminated. Wouldn’t it be better to make a definition stable enough to not throw? What is causing this odd behaviour for you? If you deal with unpredictable computation time, then maybe some sort of precheck could warn you before even starting a heavy computation. Or maybe fully eliminating Grasshopper for static duties is another, much better option! In how many different definitions are you causing this error?
I am running into the same problem regarding the “Potential Plugin Crash Protection” popup window. Ideally, McNeel could reveal how Rhino keeps track of whether such a window should be shown when restarting Rhino and Grasshopper. I suppose this must be stored in the registry, or in some file. If so, a script could be used to clean up the data which causes the popup to show. @stevebaer would you have a hint about this, or point me to someone who can help with this?
Ideally McNeel, should provide a way to mock out non-automatable or untestable code by using DI containers. Something like a ViewService or similar in this case. I just believe Grasshopper is older than this todays common technique, and a re-factoring is unrealistic. But maybe this is something to consider for GH2, if not already done so far.
As already mentioned in a previous post, there is a way on how to mock-out/replace existing functionality. I leave the research up to you. but basically you can replace class members by changing its pointer/address during runtime. This is a less known hack in C#, but its indeed doable. It allows you to override unchangeable functionality. It does not require you to patch a binary, which should make it legal or at least not illegal, but you modify the original flow of code during execution. With serious side-effects, especially if you don’t know what you are doing. I just like to mention it, because there are indeed positive use-cases for such injections, and suppressing non-automatable app features is one. But you should always carefully weigh risks against its benefit when doing something like this. But, one thing is for sure. It is unlikely somebody else is fixing it for you…
Fully agreed about the DI containers, this would be very helpful.
I found out useful details about how to avoid the “Potential Plugin Crash Protection” popups:
There is a boolean config item called ObjectServer:TrackPluginLoading in file %APPDATA%\Grasshopper\grasshopper_kernel.xml which controls in general whether load tracking of plugins happens. In case this is switched off, no such popups will appear.
The default value of ObjectServer:TrackPluginLoading is false, but it seems that in case of certain events it will get switched on automatically.
Load tracking of plugins happens using this text file: %APPDATA%\Grasshopper\PluginLoading.txt. Removing this file before starting Grasshopper is a simple possibility to prevent this popup.
Whether or not plugins are tracked during loading can be changed via the TrackPluginLoading setting. This is accessible through code via Grasshopper.CentralSettings.TrackPluginLoading, and it can be set directly in the grasshopper_kernel.xml file by changing this entry to false:
Furthermore there’s a textfile which contains the paths to plugins which failed last load. It should be here: %appdata%\Grasshopper\PluginLoading.txt. Deleting that file should also result in no tracking UI popping up.
