Hi - I have a custom compiled C# component in Grasshopper that starts a longer process using process.Start();
In Rhino5 I used Rhino.Runtime.HostUtils.DisplayOleAlerts(false); to suppress the Server Busy warning. In Rhino 6 this does not seem to work anymore. Any hints on how to avoid these warnings in Rh6 would be greatly appreciated.
Try using multithread and Task?
Yes - I get the same results since I have to call .Wait() on the task immediately. Otherwise it messes with the Grasshopper flow. Or is there something I am missing.
Some of our Grasshopper users are reporting the same issue – again only in Rhino 6. We’ve always used DisplayOleAlerts(false), but it seems this no longer does the trick?
Does anyone at McNeel have insight on this? It doesn’t happen on every machine, and not on my own – which makes it tough to troubleshoot. Trying to collect more info on the situations in which it does occur…
@nathanletwory, DisplayOleAlerts will only effect Rhino. Is something else is causing the delay, then function won’t help.
https://msdn.microsoft.com/en-us/library/785cwsb6.aspx
– Dale
@dale, if I read OP @timkado and @Jon correctly this would be within the Rhino process. I think it is interesting that this appeared to work for them in v5, but no longer in v6…
We make the call within the SolveInstance() override before synchronously running an external program, similar to @timkado, via:
process.Start();
process.WaitForExit();
This DID suppress server busy warnings in Rh 5 / Gh 0.9, but not (it seems) in Rh 6 / Gh 1. Not sure what might’ve changed under the hood.
Hi @Jon,
I’ve created an issue to remind me to look into this.
https://mcneel.myjetbrains.com/youtrack/issue/RH-49007
– Dale
1 Like
Can either of you provide me a simple way to reproduce this? I’d like to test a fix I’ve worked up.
Thanks,
– Dale
I haven’t been able to reproduce the warnings on my machine, so I’m not sure how to troubleshoot it reliably. But based on user descriptions it seems to occur with GH components that launch a long running process, e.g.
public class ServerBusy : GH_Component
{
public override Guid ComponentGuid
{
get { return new Guid("18a25920-302e-46d5-a1dd-3f198025981d"); }
}
public ServerBusy()
: base("ServerBusy", "ServerBusy", "Starts a long process", "Extra", "Test")
{ }
protected override void RegisterInputParams(GH_Component.GH_InputParamManager pManager)
{
pManager.AddBooleanParameter("start", "start", "starts a long process", GH_ParamAccess.item, false);
}
protected override void RegisterOutputParams(GH_Component.GH_OutputParamManager pManager)
{
}
protected override void SolveInstance(IGH_DataAccess DA)
{
bool start = false;
DA.GetData(0, ref start);
if (start)
{
// create temp directory
var tempDir = Path.Combine(Path.GetTempPath(), "{" + Guid.NewGuid().ToString() + "}", "myproc.bat");
Directory.CreateDirectory(tempDir);
// write batch file
var batchFile = Path.Combine(tempDir, "myproc.bat");
using (var sw = new StreamWriter(batchFile))
{
sw.WriteLine("pause");
}
// run it
var proc = new Process();
proc.StartInfo.FileName = @"C:\windows\system32\cmd.exe";
proc.StartInfo.Arguments = "/c \"" + batchFile + "\"";
proc.StartInfo.UseShellExecute = false;
proc.Start();
proc.WaitForExit();
}
}
}
Again, the above doesn’t actually produce the warning on my end, so I’m not sure how helpful this is.
Jon
I likewise have a Grasshopper script that used to work in Rhino 5 but started showing the Server Busy warning after transitioning to Rhino 6.
For my situation it happens at the end of each energy simulation. This is especially problematic as I cannot run simulations continuously back-to-back without being held up by the warning.
I’ve provided a breakout file below. (Networker component may display a warning if the Rhino model file isn’t in meters, but this is harmless and separate from the problem.)
GH breakout file (191.8 KB)
I look forward to seeing a fix to this issue.
This issue should be fixed in the next Rhino 6 SR.
https://mcneel.myjetbrains.com/youtrack/issue/RH-49007
– Dale
Hi @dale
Users are reporting that the issue persists in R6 SR11 (6.11.18348.17061, 12/14/2018). And, actually, I can now reproduce it on my machine (whereas I couldn’t with prior releases). Again, this occurs in R6 only.
I’m calling Rhino.Runtime.HostUtils.DisplayOleAlerts(false) to suppress the warnings, but to no effect. Is there something else I should be doing on my end? The warnings prevent our simulation components from working properly, so it’s a high priority issue for us.
Cheers,
Jon
Ahh, yes that does the trick on my end. 
Thanks Dale!