I have been looking through rhino common for a reference to accessing the guid of a rhino document (or even if one is assigned or created currently). I haven’t been able to find any references and suspect that it might not exist.
Would someone be able to let me know if it does exist?
If it doesn’t exist I hope that the rhino development team considers including one in future releases because it would make some file management tasks easier.
I’d like a method for identifying if an open file is already ‘known’ so that previously created 3rd party data can be assigned to that file.
Understood, and thanks for the suggestion. The documentid seems to relate to the index of a document in memory. I’m really looking for something persistent and that will be identical each time the document is opened.
usually the file path of the document could be used. Alternatively, you might create your own info, eg, cook up a GUID based on date, filename and/or filesize, save it as document data and validate it every time the document is accessed. (eg. to avoid mix-up when this document has been copied or changed, since the document data gets copied too).
I’m currently using a path method and it seems to work well - so long as users don’t manually edit their paths by moving files from one location to another or changing their name manually in the OS – thus the question to this forum.
Incidentally, I’ve looked into using the notes methods - which are also fine - but admittedly each of these methods are just work-arounds for a true solution which would be for the rhino file to have a guid assigned to it for the lifetime of the file, regardless of the assigned name, path, etc.
How can we request this feature in a future upgrade / version / etc?
using the document path should be fine as it is unlikely that you get more than one file with the same name and path.
My alternative with generating your own guid and assigning it as document data only makes sense if you need a GUID and if you are validating it because if you copy such a file, the document data gets copied with it, which makes the GUID not unique.
import System
import rhinoscriptsyntax as rs
def DoSomething():
guid = System.Guid.NewGuid()
rs.SetDocumentData("MySection", "MyEntry", str(guid))
print rs.GetDocumentData("MySection", "MyEntry")
DoSomething()
using the document path should be fine as it is unlikely that you get more than one file with the same name and path.
This is not ideal. For instance. A user makes a file, produces some geometry / work, and then saves it to a directory, maybe even their desktop. The file might be given a project name - ‘newyorktimes_renovation’. Then, they or someone else might then move this file to another directory manually when they chose to clean up their desktop.
Note:
The link is broken - it’s broken because the path has changed.
Then…
What happens if the user then comes in to work the next day and builds a new file. They call it the same name (because it’s the same project) and they also save it to the desktop - because it’s a bad habit they’ve gotten into (like all of us have)?
If using path data this new file is then determined to be the same as the former file - yet it could be quite different and it certainly is a different file.
Note:
2. The link is now not just broken but also in error because it is associated with the wrong file.
Clearly a unique GUID would be better.
How to solve the copy problem:
If a file is copied, say cut and pasted in the file system, it would have the same guid as the former file, this is true. I haven’t thought about the solution to this problem and their might not be one at the level of Rhino - this is seems to be an OS issue that needs an OS solution. You are right here.
I’m not sure if your primary concern was your only concern when you requested a document ID, so maybe I misunderstand your use case, but did you have a look at this help doc regarding User Data and Document Data?
It seems that Rhino already does exactly what you need, if you save some Document Data with your plug-in:
When Rhino reads a .3dm file and it encounters document user data, it uses the plug-in identification information to load the plug-in and then calls the plug-in’s ReadDocument() to read the plug-in’s “document” user data.
