Topic: Unique Handle Value

[jsr]

Hi Everybody

Does handle of an Entity change under any condition.

Since handles are unique only within a drawing. While combining objects from 2 or more drawings if some objects have got same handle value, what happens in such a case. Does the handle value gets change to avoid conflicts.

Thanks

[Kerry]

Hi Everybody

Does handle of an Entity change under any condition.

Since handles are unique only within a drawing. While combining objects from 2 or more drawings if some objects have got same handle value, what happens in such a case. Does the handle value gets change to avoid conflicts.

Thanks

Yes
and Yes

[sinc]

Hi Everybody

Does handle of an Entity change under any condition.

Since handles are unique only within a drawing. While combining objects from 2 or more drawings if some objects have got same handle value, what happens in such a case. Does the handle value gets change to avoid conflicts.

Thanks

Yes
and Yes

Are you absolutely sure about that?

I was under the impression that's why we use ObjectIds...

[Kerry]

Hi Everybody

Does handle of an Entity change under any condition.

Since handles are unique only within a drawing. While combining objects from 2 or more drawings if some objects have got same handle value, what happens in such a case. Does the handle value gets change to avoid conflicts.

Thanks

Yes
and Yes

Are you absolutely sure about that?

I was under the impression that's why we use ObjectIds...

Yes I'm absolutely sure.

ObjectID's are unique for a session.
Handles are unique for the life of the database.
so : incoming handles will be changed so there is no conflict ... as will incoming ObjectID's.
I'm not sure if handle numbers are incremente from the the last entity in the db or if they fill any gaps .. I have a vague recollection that they are added to the end.

[It's Alive!]

Right, handles are unique only to the drawing, store  the handle + drawing full path/name to be safe
ObjectIds are unique in all drawings open in memory.

[Kerry]

officially

http://docs.autodesk.com/ACD/2010/ENU/AutoCAD%20.NET%20Developer's%20Guide/index.html

[Jeff H]

Going off of memory but if you create a extension dictionary in NOD and store objectIds, does'nt AutoCAD remap those id's to the same objects?

[kaefer]

officially

http://docs.autodesk.com/ACD/2010/ENU/AutoCAD%20.NET%20Developer's%20Guide/index.html

Ha, hoisted by Autodesk's petard. Look under: Create and Edit AutoCAD Entities > Open and Close Objects > Work with ObjectIds.

Funny that the pages of 2011's help are at least linkable, even when it's no fun with javascript disabled.

Regards

[Kerry]

Look under: Create and Edit AutoCAD Entities > Open and Close Objects > Work with ObjectIds

yes.

thanks kaefer .


http://docs.autodesk.com/ACD/2010/ENU/AutoCAD%20.NET%20Developer's%20Guide/index.html?url=WS73099cc142f48755f2fc9df120970276f77ea.htm,topicNumber=d0e11757

You can get the page ID if you rightClick on the link and  select 'Open in New Window'

[n.yuan]

Yes I'm absolutely sure.

ObjectID's are unique for a session.
Handles are unique for the life of the database.
so : incoming handles will be changed so there is no conflict ... as will incoming ObjectID's.
I'm not sure if handle numbers are incremente from the the last entity in the db or if they fill any gaps .. I have a vague recollection that they are added to the end.

I agree that if an object from other drawing/database is brought into another drawing's database, should the coming-in object's Handle would be changed to ensure its uniqueness.

However, the OP did not explicitly say to add the objects from other drawing to another drawing's database. Since he said "combining objects from 2 or more drawing..." and not specific on "into a database" or "into memory outside drawing database", he could mean that simply read objects from more than 1 drawing and mix them together in memory for some operation. For example, in a command class's static/Shared command method with CommandFlags.Session set, a collection of Entities could be created as the class' member field, which exists in the session level, not Document level. The collection could be popultaed with entity from more than 1 drawing (assuming the entities are open for read-only). In this case, the Handle of entities would not change and yes, there could be duplicated handle across entities from different database.

[Kerry]

Valid point Norman ... though a little unlikely

I'll wait till the OP returns and clarifys his requirements before following that line of thought though.

[Jeff H]

Does handle of an Entity change under any condition.

Extended data can contain handles (group 1005) to save relational structures within a drawing. One entity can reference another by saving the other entity's handle in its extended data. The handle can be retrieved later and passed to acdbHandEnt() to obtain the other entity. Because more than one entity can reference another, extended data handles are not necessarily unique; the AUDIT command does require that handles in extended data are either NULL or valid entity handles (within the current drawing). The best way to ensure that extended entity handles are valid is to obtain a referenced entity's handle directly from its definition data, by means of acdbEntGet(). (The handle value is in group 5 or 105.)

To reference entities in other drawings (for example, entities that are attached by means of an xref), you can avoid protests from AUDIT by using extended entity strings (group 1000) rather than handles (group 1005), because the handles of cross-referenced entities either are not valid in the current drawing or conflict with valid handles. However, if an XREF Attach changes to an XREF Bind or is combined with the current drawing in some other way, it is up to the application to revise entity references accordingly.

Note: When drawings are combined by means of INSERT, INSERT *, XREF Bind (XBIND), or partial DXFIN, handles are translated so that they become valid in the current drawing. (If the incoming drawing did not employ handles, new ones are assigned.) Extended entity handles that refer to incoming entities are also translated when these commands are invoked.
When an entity is placed in a block definition (by means of the BLOCK command), the entity within the block is assigned new handles. (If the original entity is restored with OOPS, it retains its original handles.) The value of any extended data handles remains unchanged. When a block is exploded (with EXPLODE), extended data handles are translated, in a manner similar to the way they are translated when drawings are combined. If the extended data handle refers to an entity not within the block, it is unchanged; but if the extended data handle refers to an entity within the block, it is assigned the value of the new (exploded) entity's handle.

[sinc]

Going off of memory but if you create a extension dictionary in NOD and store objectIds, does'nt AutoCAD remap those id's to the same objects?

I believe it's internally storing handles, which are converted into new ObjectIds the next time they are read.  Handles persist between sessions, whereas ObjectIds do not.  Open a drawing and look at an entity, and it will have a specific ObjectId.  Shut everything down and try again, and it will have a different ObjectId.  ObjectIds are also guaranteed to be unique amongst all drawings currently open, which addresses the problem mentioned by n.yuan.  But this also means that if you are using an external database that links to entities within a drawing, you would want to use the drawing name and handle in your external database, and not the ObjectId.  (And of course, keep in mind that the user might rename the drawing.)

[It's Alive!]

There are zero ObjectIds in a closed drawing

[Alexander Rivilis]

What about _WBLOCK * to the original file name and handles persistences?