The DataCAD Developer Network (DDN) is an online resource for information and support for DCAL® (DataCAD Applications Language) developers as well as anyone interested in creating fonts, toolbars, hatch patterns, or linetypes for use in DataCAD.
#77595 by dhs
Sat Feb 15, 2020 2:39 pm
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.
#77599 by dhs
Sun Feb 16, 2020 3:32 pm
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).
#77600 by Mark F. Madura
Sun Feb 16, 2020 4:10 pm
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.
#77602 by dhs
Sun Feb 16, 2020 4:45 pm
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.

Who is online

Users browsing this forum: No registered users and 10 guests

About DataCAD Forum

The DataCAD Forum is a FREE online community we provide to enhance your experience with DataCAD.

We hope you'll visit often to get answers, share ideas, and interact with other DataCAD users around the world.

DataCAD

Software for Architects Since 1984