Topic: How to find exploded blocks

[curmudgeon]

AH HA!

I think this will actually work. I will lay out my method. There are assumptions being made here.
I assume that the block is NOT a dimension for one.

When you explode a block, the data is written sequentially. Lee helped me with a hex converter not that long ago for a very similar purpose. I think, at least in my version of Autocad, and with what very little testing I did, that when a block is exploded the new handles WILL BE SEQUENTIAL. Handles are permanent, so the sequence should also be.

So, on the back of a napkin, do this.

Insert a new instance of the block you desire, and explode it OR go through the block definition table to get the "recipe" for the block you are interested in.

Do an ssget "X" for the exact entity of the first entity of the block, and make a list of the handles. Run the list and compare the sequential handles for the pattern formed by the block.

Since there is so much chance for stuff to go wrong, I think I would have the routine zoom in on the location when it thinks it finds an exploded block.

Cool?

[irneb]

My point is you don't need to worry about the handle. The entnext function already does the sequencial bit for you. What I'm not sure about is does an explode work the same way round as (say) a select-and-copy? I.e. does it do these in reverse order? That may make for some "really" interesting coding!

[Lee Mac]

Do an ssget "X" for the exact entity of the first entity of the block...

But bear in mind that the first entity of the block definition is defined in WCS, at 1:1 scale and zero rotation.

The exploded blocks could have any insertion point, any normal, any scale (which could be non-uniform), and any rotation. All of such properties are lost when the block is exploded...

[irneb]

Yes, so the idea would be to first check for a set of consecutive entities matching the same entity types (perhaps in reverse order). Then the "real" hard part comes in: You'll need to account for such rotation, scaling (both uniform and non), ucs adjustment, etc. If all those check out, then you've probably got an "exploded" block.

The problem is how to convert to-and-from the block's internal WCS to what's in the DWG's WCS/UCS and account for rotations, mirrors, scaling and scale factor adjustments. It's difficult enought just to do that adjusting on a non-exploded block, never mind when you don't have stuff like an insertion point, normal, rotation & xyz scale factors!

[curmudgeon]

This is too much fun. entnext, yes. I can be such an idiot.

I am thinking that as the number of entities in the block increases, the chances of simply finding just the types in sequence approaches zed. How about if, for a single user and not the masses, you fix the exact matches and create a list of the those in sequence but with "problems" such as scale and UCS. Actually, maybe the scale would not be too hard to code if it were uniform.

My original application was with exploded blocks occurred when they were created or edited in Revit.
The translation back and forth to Autocad created inconsistencies. For example, so you have something to chew on, a smoke detector block would have an "S" in the middle of it, and sometimes the exploded block had the text entity - sometimes the "S" was broken down into several arc segment entities.

But that job "lost funding" and I never completed my routine to find the exploded blocks.
Which reminds me, I have to stop playing and get back to work.

cheers.

[Jeff H]

For that to work you need to know when it gets exploded so you might as well just call undo.

If you know the block,
 can you store the blockrefrences ObjectId's in a xrecord which will remap when drawing is open and store the insertion point rotaion and scale.

Then all you have to do is check if the objectId's were erased and if so use the insertion point, scale, and rotation info to find the where the exploded entites would be and insert a new block.

But seems that there must be a eaiser way by using a rector or whatever to watch for the explode command or the block being exploded and undoing it, or you trying to find a way to come back at a later point to un-explode them?   

[Chris]

well if you are going to go that far as to undo it just after it explodes, you might as well set up the block not to be able to be exploded.

[irneb]

Yep, AFAICT the idea is not to "stop" / "revert" / undo the explode command, but to get a DWG from somewhere (anywhere) which might already have these "exploded" blocks, without any "special" info about what was exploded where. So there's no way of using a reactor / redefining the explode command / making the block unexplodable. That would be like closing the gate after all your cattle's escaped. Though it would be the more "correct" and efficient way (i.e. prevention), it's rather useless in a scenario where the crime's already occurred  :pissed: .