TO Explode,. or NOT to explode.....

[+VikingRaider+]

(Done with this post).

[libbybapa]

I prefer not to explode dyn blocks unless absolutely necessary as once they are exploded they lose all dynamic functionality.

I don't know of any way to create dynamic blocks outside of block editor.

There is no easy way to save a dynamically altered block back to the block definition. You can go into block editor and make all the alterations there, though, in order to change the default state when the block is inserted.

[+VikingRaider+]

I misspoke out of frustration. The real issue is this, that sometimes an imported dynamic block comes in initially as a normal file, which must THEN be exploded to reveal the dynamism of the block. I believe this to be an incorrect method, and, preferring that the dynamic block be the direct insert: is that clear? Ps. The former, poor method also leaves a filename in your drawing with nothing in it, which is another suspicious reason to doubt its validity.

[cadtag]

I misspoke out of frustration. The real issue is this, that sometimes an imported dynamic block comes in initially as a normal file, which must THEN be exploded to reveal the dynamism of the block. ....

That would appear to be a case of nested blocks, where the dwg that's being inserted contains the dynamic block you really want.

Workaround A is to use DesignCenter to insert the block from the drawing in the file system, rather than inserting the dwg and then futzing around to get to the 'real' dynamic block.

Option B would be to WBLOCK out the dynamic blocks from the container drawing.

Not building your dynamic blocks with Option B is what is causing you grief,

[+VikingRaider+]

Thanks.

Ps. I assume now that Big-B & Big-G are essentially fraternal twins.

[libbybapa]

I used to WBLOCK each block to its own file and have since updated to a much more user-friendly method of storage and sharing. I house all of my dynamic block definitions in a single file from which I have created tool palettes for insertion. Each of the block definitions are automatically directed back to that host file. Updates are very easily accomplished. Redefining is easy. No browsing to find the block is ever required. Sharing/refreshing the tool palettes with co-workers is very easy. Blocks always come in as functional blocks without the need to explode. Specifying the default layer for each dynamic block is very easy. IMO, that method is considerably easier than WBLOCKing every block each time it needs to be altered.

[jjordan]

IMO, it is easier to keep the blocks as individual files in a directory (one for each palette). I can create a block in any drawing in any project then wblock it to the directory. Using windows explorer i can drag that file to the tool palette, and modify the properties. If i need to recreate the palette, i can use design center and pick the directory and create new tool palette, modify properties as needed. By storing the blocks in a directory, I do not have to open a drawing file to modify them (dynamic or not), i can do it from whatever drawing I am working in.

[libbybapa]

Thanks for the post. I hadn't tried dragging from Windows Explorer. Thanks for the tip.

[libbybapa]

In working with the individual block files I have found what I consider a major drawback (enough for me to not use that method). If a block contains fields, if the tool is made from a block file, on insertion the fields will not update until the user does a dynamic action on the block. If you make the tool from an inserted block, the block fields will automatically update without any dynamic action from the user.

[jjordan]

I set the field evauation variable to 23 (command "fieldeval" 23)
in the lisp file that loads for all the users, that way it will update on insertion as well as any regen, save etc.