spettitt Posted April 12 Share Posted April 12 I've written a plugin that collects a bunch of object data and pushes it out as a database, where a non-Vectorworks user can edit it. It can then be re-imported and the relevant objects get updated. I'd like the plugin to get the unique ID of the VW file and store it in the outgoing database, so if someone imports it back to the wrong VW file, it can say "This isn't the Vectorworks file your database was exported from. Give yourself a talking-to'. I've had a look through the function reference and I can get the VW file name, but not really a primary key for it. It might be a GetObjectUUID, but I don't know how to get the handle of the file itself (if there is such a thing). Thanks! Quote Link to comment
Pat Stanford Posted April 12 Share Posted April 12 I don't think there is a UUID for the file. And wouldn't you really like to be able to import the file back in even if someone had duplicated the file (which should change the UUID?) What about doing your own check. Use CreateUUID and store that value in a record. Maybe attach the record to the None class so it is unlikely to be deleted/changed by a user. Then you could use your created UUID to do your comparison. Also by doing your own, the UUID stored in a record will remain the same even when the file is duplicated so you would still be able to re-import into that file. ??? 1 Quote Link to comment
Pat Stanford Posted April 12 Share Posted April 12 I don't think there is a UUID for the file. And wouldn't you really like to be able to import the file back in even if someone had duplicated the file (which should change the UUID?) What about doing your own check. Use CreateUUID and store that value in a record. Maybe attach the record to the None class so it is unlikely to be deleted/changed by a user. Then you could use your created UUID to do your comparison. Also by doing your own, the UUID stored in a record will remain the same even when the file is duplicated so you would still be able to re-import into that file. ??? Quote Link to comment
spettitt Posted April 12 Author Share Posted April 12 30 minutes ago, Pat Stanford said: I don't think there is a UUID for the file. And wouldn't you really like to be able to import the file back in even if someone had duplicated the file (which should change the UUID?) What about doing your own check. Use CreateUUID and store that value in a record. Maybe attach the record to the None class so it is unlikely to be deleted/changed by a user. Then you could use your created UUID to do your comparison. Also by doing your own, the UUID stored in a record will remain the same even when the file is duplicated so you would still be able to re-import into that file. ??? Thanks. In this application in our office, I want to make sure it's the very same file and not a duplicate. Even if it ends up needing that ability to be reimported to a duplicate, maybe for a corruption or something, it will need a strong warning to say its not the original file. I'll have a think how else I could do it. Cheers Quote Link to comment
Pat Stanford Posted April 13 Share Posted April 13 If it needs to be the very same file, then I think storing a UUID + a date/time string to both the source file and the exported file and them comparing them on the way back in would be enough. The only issue I could see then would be you do an export and it sets the date/time. Someone then does a second export and overwrites the date/time so the person editing the first file would be told the files don't match. mumble, mumble, mumble something about foolproof and better fools. 😉 1 Quote Link to comment
JBenghiat Posted April 14 Share Posted April 14 Files definitely do not have unique id’s. In fact, I think that’s a feature— if you were to save a backup or a named version, you would want the file to be identified the same. Storing a UUID in a hidden record would be the way to go, but you would need some kind of manual connection setup between the file and database. 1 Quote Link to comment
spettitt Posted April 15 Author Share Posted April 15 Thanks guys. I'm planning this for an office environment with maybe 15-20 users of varied skill, some of which have opposable thumbs and good discipline, and others may be unintentionally rogue with taking copies of their project's master Vectorworks file from the server. We're not using Project Sharing (yet) for a few reasons, and our current server and file management works well for us, I'm just trying to consider the edge cases where user has saved a copy locally on their machine without knowing. Like you say, the fact that a stored UUID carries to a duplicate will help most users though, in the case of backups/corruption etc. I like the idea of a hidden record - for this and other things. @JBenghiat is there anything to know with making a record hidden, please? From what I can see it involves a double underscore, but I don't know if that's a cause or a symptom. Thank you Quote Link to comment
JBenghiat Posted April 15 Share Posted April 15 1 hour ago, spettitt said: I like the idea of a hidden record - for this and other things. @JBenghiat is there anything to know with making a record hidden, please? From what I can see it involves a double underscore, but I don't know if that's a cause or a symptom. The double underscore will hide a field. To hide a record, use SetObjectVariableBoolean on the record format with the selector 900. (True is hidden). Usually I check if the record exists, if not, create it, then hide. The record otherwise functions as usual, and you can create a script to toggle visibility as you're testing. Quote Link to comment
spettitt Posted April 15 Author Share Posted April 15 Excellent, thanks for this. Quote Link to comment
Pat Stanford Posted April 15 Share Posted April 15 And you can attach the record to a Layer or Class rather than a visible object to provide additional obfuscation. That way you would have to access the Record via a script as even if it is visible there is no way to select the object to edit the record. 1 Quote Link to comment
JBenghiat Posted April 15 Share Posted April 15 If it’s for a document-wide setting, you don’t have to attach the record to anything— just use the default field values to store your data. You can get a handle to a record definition by its name. 1 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.