The object exists in your code, so that's not the issue. One thing to do is take it a step further and access a property on the entity via an object property call that you know all the object will have like a layer. So trap the level to get the object and then trap again at the property level.
Whenever you decide to use vl-catch-all-apply, you should ask yourself if you care why something is not failing. If the answer to that is yes, then you need to explore the reporting features built-in to the feature. Obviously, from your post, you care about why things are failing and are complaining about the lack of reporting.
But when you choose to use vl-catch-all-apply, you are taking on the task of managing reporting yourself. Look up the vl-catch-all-error-message function.
For your code, which doesn't have sufficient right parentheses BTW.
Here you need to save: 1)The ename from (ssname.... ) before you save 2)The obj variable.
Unless you have localized OBJ, then OBJ in the code could be whatever it was before the code started. With vl-catch-all-apply, there is no error and therefore no error handling or break on error or error tracing. All you have is assumptions unless you take control.
After adding the save steps above, trap the error. Don't just pass it to vl-catch-all-error-p. Save the return value of the vl-catch-all-apply expression. It may be as simple as a failure to supply sufficient arguments to the vl-catch-all-apply function. In your code, you should include a null list if for documentation purposes if not required. Once you have saved it, you can check it.
I would suggest that you replace vl-catch-all-apply with the apply function until you understand the errors.
actually I would say I don't care in this case why its failing, as I just skip any entity that is, or stop the routine and tell the user their drawing is ugly.
Does not matter, your comment applies to many situations where I do care, so want to understand your idea.
I'll see if vl-catch-all-error-message helps.
I use the VLIDE so easily catch paren matching errors, just got sloppy pasting in or something.
Also, all variables are localized, but setting obj to nil and then testing if its nil after the assignment would be more conservative.
I'll play a bit more.
John asked if the c3d civil batch converter could be the issue, and its not.
I do not run that on my sheets, just incoming files I use for bases (xrefs).
The xref with invalid ename is super clean when I open it. And I've struggled with dirty drawings for so long now my standard of clean is pretty high.
Awesome comments from all so far, thx
internal protected virtual unsafe Human() : mostlyHarmless I'm just here for the Shelties
There is no reason why a normal selection set will cause an error when accessing with ssname unless the index is out of bounds. That means that the first object is index 0 and the last object index is sslength -1.
An attempt to access an entity that was erased between the time that the selection is made and the time the ssname is returned results in the deleted ename.
An attempt to access entity information with entget on a deleted entity will not result in an error, just nil.
A deleted object can be undeleted with (entdel ename).
Once it is undeleted, its information can be returned.
So there is something going on with your situation. Post the whole code. The problem isn't in the posted section.
remember that the sheet I am dealing with has a minor corruption.
Everything behaves if I Audit the file, it fixes one thing, and its related to the xref.
I agree with all you are saying and appreciate the attention you have given.
I'm still ripping the drawing apart, meanwhile also convincing someone in my riverside office that their drawings open slow due to civil3d styles, not excess annotation scales.... I must spend 2 hours a day helping teams keep their drawings stable.
thx
internal protected virtual unsafe Human() : mostlyHarmless I'm just here for the Shelties
Autocad 2015 vanilla. TEST routine showed me 19 good, one wrong. AUDIT erased the wrong one. (command "erase" (SSGET "X") "") erased 18 proxy objects. Only a VIEWPORT left the drawing. Not sure what that means...
AcDbRegAppTable(9) Invalid AcDbRegAppTableRecord was removed. Pass 2 700 objects auditedAcDbBlockReference(5A364) BTR Id invalid AcDbBlockReference(5A364) could not be repaired. It will be Erased. Pass 2 3000 objects audited Auditing Blocks
0 Blocks audited
Auditing AcDsRecords
Regenerating model.
Total errors found 3 fixed 3
Erased 1 objects
Command: (setq ss (ssget "x" '((0 . "insert")))) nil
What if you use the method we discussed before about accessing it via object methods, specifically ObjectName and then checked if it is ; ObjectName (RO) = "AcDbZombieEntity". Cheking the entity that is giving you grief it shows to be a Zombie. Then skip the entity and move on through your process. I'm running in AutoCAD 2017 Plain with out any OE's loaded. I assumed that was how you were running it. I believe your goal is to work through your process without getting bogged down on irrelevant entities. You can flag it for review to your group and move on.