Jump to content
Hippocode

Converting internal indexes between drawings

Recommended Posts

Posted (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 by Hippocode

Share this post


Link to post

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. 

Share this post


Link to post

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.

Share this post


Link to post

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.

Share this post


Link to post
Posted (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 by Neatworker

Share this post


Link to post

@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

Share this post


Link to post

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

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

×