Rhino.RhinoDoc.Import not running headless

We got a problem calling Rhino.RhinoDoc.Import from a thread that is not the UI thread. The headless document is created immediately beforehand using RhinoDoc.CreateHeadless. This is the stacktrace of the exception that happens (lowest two calls are our own code):

Exception when reading file: The calling thread cannot access this object because a different thread owns it.
   at System.Windows.Threading.Dispatcher.VerifyAccess()
   at MS.Internal.Media.VisualTreeUtils.AsVisual(DependencyObject element, Visual& visual, Visual3D& visual3D)
   at System.Windows.Media.VisualTreeHelper.GetParent(DependencyObject reference)
   at System.Windows.UIElement.GetUIParentWithinLayoutIsland()
   at System.Windows.ContextLayoutManager.LayoutQueue.Add(UIElement e)
   at System.Windows.UIElement.InvalidateArrange()
   at Eto.Wpf.Forms.WpfFrameworkElement`3.Invalidate(Boolean invalidateChildren) in D:\\BuildAgent\\work\\commercial\\src4\\DotNetSDK\\Eto\\src\\Eto.Wpf\\Forms\\WpfFrameworkElement.cs:line 355
   at Eto.Wpf.Forms.WpfContainer`3.Invalidate(Boolean invalidateChildren) in D:\\BuildAgent\\work\\commercial\\src4\\DotNetSDK\\Eto\\src\\Eto.Wpf\\Forms\\WpfContainer.cs:line 55
   at RhinoWindows.Forms.StackedDialogPageService.RedrawPageControl(Object pageControl)
   at Rhino.UI.PanelSystem.OnVisiblePanelCallback(Guid panelTypeGuid, Guid hostId, UInt32 documentSerailNumber, UInt32 state)
   at UnsafeNativeMethods.RHC_RhinoReadFile(UInt32 docSerialNumber, String path, IntPtr pOptions)
   at Rhino.RhinoDoc.Import(String filePath)
   at ShapeDiver.Public.Grasshopper.Import.RhinoHeadlessDocumentLoaderSingleton.LoadUsingRhino(Stream stream, String file_extension, Boolean scaleUsingCurrentDocument, String& err, List`1& outputMaterial) in C:\\Program Files (x86)\\Jenkins\\workspace\\GrasshopperCompleteRhino7\\SdGhPublicLib\\Grasshopper\\Import\\RhinoHeadlessDocumentLoaderSingleton.cs:line 310
   at ShapeDiverForGrasshopper.ShapeDiverGeometryImportComponent.HandleDataStream(IGH_DataAccess DA, Stream stream, String content_type) in C:\\Program Files (x86)\\Jenkins\\workspace\\GrasshopperCompleteRhino7\\ShapeDiverForGrasshopper\\Parameters\\ShapeDiverGeometryImportComponent.cs:line 15

This doesn’t happen for each Rhino document that gets imported. It appears that depending on the content of the Rhino document, the UI panels are being accessed or not.
Note that Rhino is not running headless in this case. However, I believe a headless document should always be entirely headless. This is a big problem for us. @stevebaer would you have any hints?

@stevebaer we talked about this in Barcelona. Please let me know whether you had a chance to look into it.

I’ve been under pressure to get Rhino 8 finished up ever since Barcelona and haven’t looked at this yet. Have you tried this in Rhino 8? I turned off event watchers with headless docs by default which I’m guessing are what are causing problems in this case.

I will try reproducing it using Rhino 8 and get back to you. In case this solved it, any chance of fixing it in Rhino 7?

Probably not; we would need high confidence that we are fixing a specific bug and not introducing new bugs by making this change.

@stevebaer interestingly, a popup which I have never seen before started appearing in Rhino 7 when running the headless import (sometimes).

Could you please check what might cause this?

Hi @snabela,

When Rhino is in the process of loading a plug-in, it cannot load another plug-in.

You can get this message when the plug-in being loaded is doing something in it’s OnLoad override that causes another plug-in to load.

Does this help?

– Dale

@dale this happens while calling Rhino.RhinoDoc.Import on a headless document in Rhino 7 as described on top of the thread. Unfortunately, it only happens sometimes.

@stevebaer we are close to starting heavy testing using Rhino 8. However, I need to find a solution for this for Rhino 7 as well. You mentioned the following:

Is there a way for us to do that (turn off event watchers)? If so, could you give me a hint please?

@stevebaer @dale please see my previous message.

@stevebaer @dale jumping in here: This problem makes it impossible for our users to reliably import any 3dm file as part of any ShapeDiver tool right now. We get more and more requests from customers who need to execute automated workflows based on existing Rhino files, and we ourselves are working on new functionality based on 3dms as well.
None of this works if we can’t import 3dm documents.

It would be great if this were fixed for Rhino 8, but our customers sometimes have very large and elaborate Grasshopper scripts that they built using Rhino 7 and don’t want to adapt.

So we need to find at least a workaround for this problem - of course, a fix on your side would be ideal. Could you take another look?


Sorry for not replying sooner; it’s been a bit hectic. Have you tried using Rhino 8 for this? That would be the first thing to try to see if my changes in Rhino 8 made a difference.

Hi @stevebaer, many thanks for your feedback, we are on it. I will let you know as soon as I know more.

@stevebaer quick feedback about headless document import in Rhino 8 so far: The problem seems solved, and importing works much faster. That’s amazing!

Caveat: I will update this thread once we have done more testing because the problem did not appear for all imports.

Update about Rhino 7: I found a potential workaround by ensuring the import runs on Rhino’s UI thread. I will update this thread once more tests have been carried out.