forum.datacad.com

I have a scenario where I a macro is storing the address of an entity in a system attribute.
On startup the macro gets the attribute and if it exists then does an ent_get using the lgladdr in the attribute. The behaviour of the macro is then slightly different depending on the return value of the ent_get call.

I have an issue if the entity whose address is stored in the attribute has subsequently been erased: ent_get is still returning true (and the details of the entity are returned in the ent parameter) even though the entity has been erased. (Note: Problem does not occur if PurgeDrawingsOnExit is set to 1 in the ini file and the drawing has been saved since the entity was erased ... ent_get is correctly returning false in this case).

The entity record returned by ent_get for the erased entity appears to be 'correct' (i.e. same as was returned before the entity was erased). The macro actually calls the hi_lite procedure with the returned entity and it is being hilited on the screen as though it had not been erased.

Is there a way to tell that the returned entity has in fact been erased? I don't notice any field in the entity definition that looks like it would indicate the entity was erased (I thought that perhaps the lyr field may be set to nil but that appears to still have the original [undeleted] value). Is it even advisable to store an address like this (or might a file purge move things around?)
Any advice would be appreciated.

Thanks,
David H.

Is it even advisable to store an address like this (or might a file purge move things around?)

I have given this a bit of thought (and done a bit of testing), and have verified that a stored address may not always point to the entity you originally selected ... if you delete that entity and a file purge is done then a new (completely different) entity may end up residing at the same address that the deleted entity previously had.

I would rather have my macro not identity the entity at all (and force the user to identify it again) than to identify the wrong entity. One way to identify an entity is to add a specific attribute to it and then search for an entity with that attribute on a subsequent invocation of the macro. But there are issues if the entity has been copied (together with its attribute) in the meantime. So I think that my solution will be to add an atr_addr attribute to the entity which stores its own address ... I can then not only search for an entity with that attribute, but can also check that the attribute is storing the same address as the entity it is attached to. I think this is an appropriate use of an atr_addr attribute, but I doubt that it is appropriate to use these attributes in most scenarios where you are going to use the address to retrieve an entity (or layer, polyvert, view, or anything else identified by an address).

When an entity gets erased, the entity.next and entity.prev addresses are changed to 'point around' the deleted entity(ies). When the file is closed and saved, the orphans are purged out to reduce file bloat. So, entityA.next should equal entityB.prev and so on.

Thanks very much for your comments Mark,

It is obvious that my original logic (of simply storing an address in a system attribute) is not a valid approach. There is no easy and reliable way to tell if the entity retrieved via a stored address has in fact been deleted, or even if it is still the same entity that was originally identified.
I will modify my logic as per my previous post, so this is no longer an issue for me.