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?
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.
@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 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.
@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.