Confusion over Document.RuntimeSerialNumber during RhinoDoc.Open

I’m working on unit testing (thanks ShapeDriver crew for the plugin template!) the serialization behavior of my plugin, and trying to make sure that I’m capturing behavior correctly. I am attempting to key plugin data off the RuntimeSerialNumber, but I’m very confused about the behavior I’m observing.

The associated RhinoCommon test code looks like

//Create new file
var newRhinoDoc = RhinoDoc.Create(string.Empty);
var sn1 = newRhinoDoc.RuntimeSerialNumber;
//Get a TempFileName
var testFileName = Path.GetTempFileName() + ".3dm"; 
//Save the File
newRhinoDoc.WriteFile(testFileName, new FileWriteOptions());
//Close the File
//Open the saved file
var openedDoc = RhinoDoc.Open(testFileName, out var wasAlreadyOpen); 
var sn2 = openedDoc.RuntimeSerialNumber;
//Reopen the saved file
var reopenedDoc = RhinoDoc.Open(testFileName, out wasAlreadyOpen);
var sn3 = reopenedDoc.RuntimeSerialNumber;
var activeDoc = RhinoDoc.ActiveDoc;
var sn4 = activeDoc.RuntimeSerialNumber;

When I get to the end of executing this code, the serial numbers are something like:

sn1 == 1
sn2 == 2
sn3 == 2
sn4 == 3

When handling the openDocument events for reopening the existing document, the serial number provided in the DocumentOpenEventArgs is sn4, but the document returned from RhinoDoc.Open has sn2 as it’s serial number. Is this the expected behavior when reopening an already opened document? It seems to me that sn3 == sn4 should be the expected behavior. I can see why reopening a document should in theory result in a document with the same SerialNumber, but then I’m confused as to why the ActiveDoc has a different serial number.

In practice, for RhinoWindows, this isn’t an issue as the current document is closed before the new document is opened. But I could see this being an issue for Mac and RhinoInside users.

Hi Cullen, sorry for the delay in getting to this. I’m not sure exactly what is going on, if this is expected behavior or not. I can certainly reproduce it and I will check to see if I can find out what is going on. Meanwhile this is tracked in the following YT item:

1 Like

A fix has been made and will get into Rhino 8SR10 (mid August).