Hippocode Posted January 6, 2018 Share Posted January 6, 2018 (edited) Hi I have objects that reference others by an internal index. Basically it's a list of objects A that reference any other object (any type) named B by their internal index. This reference is saved into a Sint32 Parameter. When referencing this file into an other document (e.g. layer viewport), the references are broken because they assume the indexes remain the same, which they don't. Is there any way to find out the new indexes relative to the other document so I can correct the internal indexes to their correct values? Edited January 6, 2018 by Hippocode Quote Link to comment
Pat Stanford Posted January 7, 2018 Share Posted January 7, 2018 The best/only way would be to attach a record and store a UUID (VS CreateUUID procedure) and then use that to either replace the internal index or to find the internal index. Quote Link to comment
Conrad P Posted February 23, 2018 Share Posted February 23, 2018 UUID in the object name is the way to go. According to Vlado the name table is indexed and is fast. Internal uuids are not indexed. My 2p worth. Quote Link to comment
Pat Stanford Posted February 26, 2018 Share Posted February 26, 2018 Using the object Name has an additional benefit. The Name is required by VW to be unique and VW enforces that. If you duplicate a named object, the Name of the duplicate will be cleared. I would love to have that capability in a hidden, scriptable field as well. Quote Link to comment
Conrad P Posted March 8, 2018 Share Posted March 8, 2018 (edited) Well Pat as you probably know it's not all that simple. VW silently changed the behaviour of object names under duplication following a customer request. So now <uuid> becomes <uuid>-2 after copy-paste and duplicate. BUT... if you dare duplicate a layer you'll find all your objects with blank names again. There are also some fun variations on the this theme during symbol placement too. I think I've seen the old 'none' value (guess what handle you get when you ask for an object called 'none' ;-) ? In fact the new way of doing this is very neat for us developers. Because if you are using uuids to relate objects the -2 suffix makes it a breeze to locate the duplicated 'friend' of your duplicated object if you see what I mean. So I have entered an improvement request to get this policy applied across the board. Would also be nice if PIOs would reset on layer dupe too.... Oh well back to it I guess... Conrad the Greenhorn Edited March 8, 2018 by Neatworker Quote Link to comment
Pat Stanford Posted March 9, 2018 Share Posted March 9, 2018 @Neatworker. Conrad, I was not aware this had changed. I guess I should not comment on things I have not tried in a few versions ;-) I appreciate the update. It starts with -2? Don't most programs start with -1? Oh well just another VW idiosyncrasy. it is actually nice the keep a kind of link between objects. I woukd still till like to have a private field type that shows this behavior GSX Name can be used by the end user.. Pat Quote Link to comment
Conrad P Posted March 18, 2018 Share Posted March 18, 2018 Pat, the whole thing is a bit iffy. Basically all objects need UUIDs once you start to deal with concepts like linkage between them. And that should be embedded in the app. In SDK there is an internal UUID but the word I have from VW is that the table is not indexed so finding a handle from this id involves searching. Inevitably that will slow down to a crawl as the drawing gets bigger. So I'm stuck with the object name with its good and bad features. Taking a wider view, CAD started out as a replacement for drawing boards, pencils and big sheets of paper. But it is no longer that. Now it is a modelling environment and our expectation is to be able to extract meaningful data from our drawings. Concepts like containment, connection and membership of abstract (non-visual) sets are still not built-in. Adding things like this as an overlay is a lot harder. It's like we're stuck in the '90s. We can draw a line on the screen and measure its physical dimensions but, in our design that line MEANS something. It's part of a model of what we're going to build. Other things are located at it's end points, it crosses boundaries, it's inside certain areas. All that information is still very hard to get at. From my perspective it's not a question any more of optimising what we have. Tweaking just won't cut it. The conceptual level has be lifted out of geometry and into actual design components. Sure we need geometric primitives to design the perfect washbasin for example. And you'll play around with NURBS and all that good stuff. But once you're done that washbasin component goes in a restroom. And the restroom is contained in a section of the building. To function the washbasin needs hot and cold water and a waste connection. It generates flows in these systems that need to be estimated. Yes we've got the geometry, but where's the systems modelling? Must be some 15 years I've been trying to get this message through... Always good to talk anyway. Conrad 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.