Jump to content
Developer Wiki and Function Reference Links ×

[C++] Unique Identifier for Objects


KQPap

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 

 

Link to comment
  • 2 weeks later...

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.

Link to comment

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. 

Link to comment
  • 3 weeks later...

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.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...