Jump to content
Developer Wiki and Function Reference Links Read more... ×
KQPap

[C++] Unique Identifier for Objects

Recommended Posts

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 

 

Share this post


Link to post

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.

Share this post


Link to post

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. 

Share this post


Link to post

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.

Share this post


Link to post

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

 

7150 Riverwood Drive, Columbia, Maryland 21046, USA   |   Contact Us:   410-290-5114

 

© 2018 Vectorworks, Inc. All Rights Reserved. Vectorworks, Inc. is part of the Nemetschek Group.

×