Entity Validity Check

Parent Previous Next

Entity Validity Check


Sometimes it is necessary to verify whether a given is erased or alive ... the entity is either available as ENAME, HANDLE or VLA/COM-Object.

For the case of a given HANDLE, using (handent string) function returns NIL for an erased or non-existing entity without performance issues.
For the case of given COM/VLA-Object, using (vlax-erased-p vla-object) returns the correct status without performance issues.

But the performance issue arises in the case of given ENAME :
The often seen, usual approach is to use (entget ename) as in
Examples :

(if (entget ename) ...)     ;; entity is alive
(if (not (entget ename)) ...)    ;; entity is erased


If the entity is not erased, (entget) generates the entire definition-data list, which is a significant overhead, and wastes performance and Lisp memory, which in turn triggers more GarbageCollections - only to verify whether the entity is erased or not.

Suggested code version :

(vlax-erased-p ename) - other than documented, it also accepts an ENAME, in both AutoLISP and BricsCAD Lisp
(vlax-ename->vla-object ename) - is a good alternative (but a bit slower), if the VLA-Object is either needed for later use


Obviously, (vlax-erased-p) gives the best performance here, without wasting Lisp memory.

Important Remark :
Using (entget ename) could fail for a valid, unerased entity during several (database/object) reactor callbacks, if the entity in query triggers that reactor, directly or indirectly !
To generate the (entget) data, the entity needs to be (re-)opened for read access, which will fail when it is already opened in write mode !
BricsCAD's database engine (ODA Teigha) is sometimes more tolerant here - but there is no guarantee in generally to have (entget) always succeeding !
Using (vlax-erased-p ename) is safe under such conditions - the erased status is directly retrieved from the "ename" (ObjectID) value without opening the entity.




©  Menhirs NV. All rights reserved.