Help finding the relevant Block so Layer 1 can be Purged

[rkmcswain]

The block definition.

If you drill it down, layer "1" is referenced in the anonymous block "*X6"
(A04119 contains an INSERT of this anonymous block).

[bjack56]

So how did you find it & what is the solution?

[rkmcswain]

So how did you find it & what is the solution?

I didn't try every trick in the book, but I didn't see layer "1" in there by using normal means. However, as soon as you purge the block "*X6", then layer 1 becomes elegible for purging. Maybe layer "1" is referenced in xdata contained in this block....

SuperPurge is good for these types of problems.

[jaberwok]

I used Wblock and picked each block, one at a time, from the dropdown list then opened the new file.

[ralphsanchez]

Ten years ago, Jay Garnett wrote a LISP routine, MYSTERY, which prompts you for a layer and then shows you a list of all of the blocks in your drawing that contain entities on that layer. The code can be found in his post here. I still use it to this day. A zip file containing the LSP and DCL files is attached..

[Rico]

Cool info ... didn't know how to do this sort of thing. Something new learned today.

[rkmcswain]

Ten years ago, Jay Garnett wrote a LISP routine, MYSTERY, which prompts you for a layer and then shows you a list of all of the blocks in your drawing that contain entities on that layer.

That lisp doesn't work on this drawing.

One reason is that it skips anonymous blocks, but even if you bypass that, it still doesn't find it.

Ok, I found the culprit. The ENDBLK entity of the block *X6 is on layer "1".
Apparently, whatever created or last edited this block introduced this error since I'm guessing that the ENDBLK entity should always be on the same layer as the BLOCK entity.
Neither RECOVER or AUDIT catch it either.

To query this entity, do this:

(entget (handent "4e95c"))

[ralphsanchez]

Thanks for the info, RK. I've never seen anything like this, and I'm obsessive about clean DWG files. Was A04119 originally hatched in AutoCAD, bjack56? Based on the fact that the layername is "1" and that *X6 isn't a regular AutoCAD hatch, I'm guessing it may have come from Microstation somewhere in its history.

As RK pointed out, this emphasizes how nice superpurge is, since it easily takes care of the layer 1 problem in that DWG when using the "hard" option. Interestingly, after erasnig ALL, even spurge seems to have trouble purging the block block TICK1 from that drawing.

That lisp doesn't work on this drawing.

One reason is that it skips anonymous blocks, but even if you bypass that, it still doesn't find it.

Ok, I found the culprit. The ENDBLK entity of the block *X6 is on layer "1".
Apparently, whatever created or last edited this block introduced this error since I'm guessing that the ENDBLK entity should always be on the same layer as the BLOCK entity.
Neither RECOVER or AUDIT catch it either.

To query this entity, do this:

(entget (handent "4e95c"))

[rkmcswain]

Thanks for the info, RK. I've never seen anything like this,

Remember back in R14, there was a bug that allowed programmers to create a SEQEND entity with a layer different than the layer of the VERTEX entities when using (entmake) to create a POLYLINE.

This is similar although I don't know if you can do this on purpose using VBA or LISP in 2004/5/6/7

[bjack56]

Thanks for all the help & info....I will try some of the fixes after my deadline for getting the Bid Set drawn passes in the next couple of days.

I have no idea where this originated, but it has cropped up from time to time in my drawings, probably some Civil Engineer....JUST KIDDING!!