Continuing the discussion from Multithreading with rhinocommon:
This question is particularly environment-related. Are you just trying to Open the file?
If not, are you using Batch, Insert or New modes?
If yes, are you using Rhino 5 on Windows or on Mac or Rhino WIP? In WIP, we suggest to use RhinoDoc.Open(), which works differently on Win and on the Mac (Mac Rhino is multi-object). That is also the best method to call if you have access to it. Otherwise, I would suggest OpenFile(). Can you have a look at this? You can also just script the Open command.
Using Rhino5 on Windows. with this declaration for read options
var fileReadOptions = new Rhino.FileIO.FileReadOptions();
fileReadOptions.ScaleGeometry = false;
fileReadOptions.BatchMode = true;
fileReadOptions.NewMode = true;
I can’t use RhinoDoc.Open() since it is in Rhino6 and we dont use it yet… and yes i know about OpenFile and scripting but the problem remain… it works on my computer… but sometimes crash on customers computers… I really dont know how to force the error to come out… but after putting all the code that the idle event is running in the Invoke of the rhino main form the functions break on Add() or Duplicate() functions… never more in the readfile… but who knows… maybe tomorrow i’ll get an email (i get an email on bugs that force the application to close) with the call stack of some customer with a crash on it since is not happening that often…
I was wondering if some of you looking at the code in read file function could find out something… and Why if i run the code in the idle event and i put the readfile function in the invoke of the rhino mainform after it, using RhinoApp.Wait() before getting rhinoObjects from the ActiveDoc change the behavior?
I don’t know, but thanks for the detailed explanation. Let’s see if @stevebaer knows or encountered this.
meanwhile, as i suspected, i got an email with a crash
at UnsafeNativeMethods.RHC_RhinoReadFile(String _path, IntPtr pOptions)
at Rhino.RhinoDoc.ReadFile(String path, FileReadOptions options)
called inside the invoke from the rhino main window… during the idle event…
I’d like Steve’s opinion on this, but my first guess is that the Idle event should call a command. That is because any RhinoDoc operation is thought to happen inside a command, usually.
Only from the command, then, you would call the ReadFile method.
However i’ve see in the environment call stack that the idle event is invoked by the Rhino main window so the invoke isn’t required… and about beeing inside a command my plugin don’t even implement a run function. It create a new class on load event wich wait a udp call to show a wpf docked above Rhino… so i cant even use the Rhino doc from it…
Whatever you are up to, to do anything to the document you need to be in a command. Rhino uses the command information to store Undo information (and more) – that is why you usually need to do that. In the idle event, you should call a command with the RhinoApp.RunScript("_MyCommand", false) method. Then, your command’s RunCommand method will be run. There, but nowhere else, you can safely do stuff to the document.
Alternatively, your UI can invoke the command directly, always with the method above. This is the usual way for all our standard toolbars.
Peraltro, se sei italiano possiamo anche scrivere in italiano.
I have read about those problems working with RhinoDoc.ActiveDoc… will try to move the code to some commands. Thanks for your feedback.
Si sono italiano ma preferisco l’inglese così se qualcun altro ha lo stesso problema può leggere (anche se il mio inglese non è un gran che).
I may ended up resolving the crashes. Moving the code to scripts and refactoring a bit of that legacy code made me found some functions that was closing the views from C# code. After moving the code closing and leaving a single top view in a script it’s been more than 3 weeks that i dont have a crash from customers.
So lesson learn: Dont close views from C# and immediatly after open a rhino file and vice versa, instead close them from a script and wait it to end.
Hope it will help someone else.
Interesting. Thanks for the heads up.
I think a crucial point here is having moved logic to an independent command.