KQPap Posted November 20, 2018 Share Posted November 20, 2018 Hello, I'm looking for a way to always uniquely identify objects in Vectorworks across multiple sessions and after conversion to a higher version. I'm using C++ Maybe I misunderstand it too, but the way I see it, objects in VW don't necessarily have a GUID immediately. And even if a GUID exists, it can change. And the only way I identify objects is via the handle - but I can't use that to store it across sessions (I think it's actually just a storage address). This also works fine in a single document, but I encounter problems when several people open the file in different versions (my plugin writes to a database in the background). Following scenario: A file is opened with VW 2016 and the user creates a door, enters information (without GUID) and saves the file. My plugin writes information to a database. He opens the same file in VW 2018. Does my plugin have any chance to recognize that the said door already exists in my database? Is there any kind of UUID that is created immediately and does not change when it is converted to VW2018? Best Regards Patrick Quote Link to comment
Pat Stanford Posted November 30, 2018 Share Posted November 30, 2018 Have you met the Chance Brothers? Slim and No? Just kidding, but what you are asking is not easy in VW, but it is possible. The only place in VW where you can be guaranteed to have a unique value is in the NAME field in the OIP. You could store your GUID there, but that is also used by some users and in some objects for other uses. Also, it is use accessible, so there is no way to keep someone from changing the value and messing up your database. You best option is probably to create a hidden record format and use that to store a UUID. In Vectorscript, there is a CreateUUID function, so it is probably in the SDK also. Basically, your script would first check for an instance of the hidden record. If it is not there, it would attach the record, create the UUID, and store the UUID into the record. Then that UUID could be stored into your database. Come time to go backwards, you would have to look for an object with a record.field value equal to the UUID in the database. What you do when you don't find and object depends on your needs. You might want to reach out to @John McKernonand see if he can offer any advise. His LightWright lighting paperwork program handles back and forth between VW and Lightweight robustly. That seems similar to what you are talking about. Quote Link to comment
JBenghiat Posted November 30, 2018 Share Posted November 30, 2018 Objects in VW do have a UUID, but only recently— starting in 2017 or 2018. The SDK has routines to read and write the UUID. You are correct that you shouldn’t rely on handles, as they are just addresses and don’t persist among sessions, and even within a session a handle can be re-assigned if an object is deleted. If you need an identifier for database purposes, you need to write to the object’s name. The name is unique by definition and indexed, so access is fast. You can come up with your own indexing scheme, or there is also a class for generating a UUID. Quote Link to comment
Stefan Bender Posted December 17, 2018 Share Posted December 17, 2018 Creating a UUID and storing it in a hidden record format won't work. If a user or an SDK routine duplicates the object, the record of the duplicate will have the same UUID than the record of the original. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.