To nest or not to nest blocks in dynamic blocks

[tim.101799]

I have many old blocks of light fixtures that I want to turn into Dynamic blocks. When creating a DYN block with multiple visibility states, should I create a new dynamic block with several other blocks nested into it (one block for each visibility state) or should all the visibility states contain only line work (no nested blocks).

Tim

[Rico]

I have many old blocks of light fixtures that I want to turn into Dynamic blocks. When creating a DYN block with multiple visibility states, should I create a new dynamic block with several other blocks nested into it (one block for each visibility state) or should all the visibility states contain only line work (no nested blocks).

Tim

Personally, I stay away from Nested Blocks. It makes it harder to edit properly. If there is something that you need to change in the regular block but NOT in the DB, the DB will be changed anway because the block is also used for the DB.

Plus there's issues with layers, purges and other stuff. and let's not go into what happens with nested blocks inserted as Xrefs into another drawing.

My personal opinion is that nested blocks are pains inthe butts. Other people may have other opinions, but that's mine. I explode said blocks and convert them to regular CAD objects (lines, arcs, Plines etc)

[Chris.N]

Personally, I stay away from Nested Blocks. It makes it harder to edit properly. If there is something that you need to change in the regular block but NOT in the DB, the DB will be changed anway because the block is also used for the DB.
(snip)

that's happened to me, and the reason i don't use regular blocks in my DB's.

[r424andy]

About the only time that i use nested blocks is if I have three or so DB that i want to insert at a time.
Very useful for tool pallets when exploded on insert. All the inserted blocks retain the unique dyn states.

[wroebuck]

I nest dynamic blocks to manipulate them in a specific order via user or VB. One example, I have a beam with different end conditions. I show multiple side views of the beam, each with different information for clarity. So I have 4 DBs each end of my beam that I nest into a larger DB of the entire beam. That way the user or from VB we can stretch the beam to a new length, explode it, and manipulate the ends as required. I haven't had any problems in this case.

[Chris.N]

I nest dynamic blocks to manipulate them in a specific order via user or VB. One example, I have a beam with different end conditions. I show multiple side views of the beam, each with different information for clarity. So I have 4 DBs each end of my beam that I nest into a larger DB of the entire beam. That way the user or from VB we can stretch the beam to a new length, explode it, and manipulate the ends as required. I haven't had any problems in this case.

could you post the example? or if the block is proprietary, supply screen shots illustrating the procedure? it sounds like an interesting arrangement. Thanks!

[Rico]

I nest dynamic blocks to manipulate them in a specific order via user or VB. One example, I have a beam with different end conditions. I show multiple side views of the beam, each with different information for clarity. So I have 4 DBs each end of my beam that I nest into a larger DB of the entire beam. That way the user or from VB we can stretch the beam to a new length, explode it, and manipulate the ends as required. I haven't had any problems in this case.

Let me clarify .... If there is a PURPOSE for the nesting ... and IF it's easy for you to re-connect the dots and edit the nested blocks, then it's fine to do so. The reason I imply that nesting is not good is because most people who will use DBs will not require nesting as a part of the typical DB function. Plus some people don't even know how to do nesting. For the more advanced and for those who understand, it's different.

Personally, I understand how to nest and why to do so, yet I do not do it because I don't feel it's necessary as a part of my daily work life here at my company, plus the people I work with do not have a good grasp of the basics of AutoCAD, let alone something more advanced liek DBs for it to be implemented properly.

I wouldn't mind seeing one in action, though (hint hint)

[wroebuck]

I understand completely. I wasn't trying to take a shot at you. I only posted to show both sides on the nesting issue. I agree with you, there must be a purpose for it. I work for a structural engineering firm and we draw precast shop tickets to create beams, girders, columns, etc. So to be able to draw a similar object over & over is the daily grind. We have been able to automate the entire process. That I can't give out but I have a severely edited version of the basic principle. Here is 1 side view of a beam with 3 different end conditions. Trust me there is a lot more to it than this. Our process is ran off the attributes in plan files. We pull them to excel, to run a few formulas on them and then use Visual Basic to create, modify and save the individual drawing off. the drawings consist of 1 nested block that contains most of the drawing. That nested block contains about 30 to 35 dynamic blocks. Using VB and the data from excel, we modify each dynamic block so that the end result is the final drawing. Very fast, no human error unless it was in the initial template setup.

[Rico]

I understand completely. I wasn't trying to take a shot at you. I only posted to show both sides on the nesting issue. I agree with you, there must be a purpose for it. I work for a structural engineering firm and we draw precast shop tickets to create beams, girders, columns, etc. So to be able to draw a similar object over & over is the daily grind. We have been able to automate the entire process. That I can't give out but I have a severely edited version of the basic principle. Here is 1 side view of a beam with 3 different end conditions. Trust me there is a lot more to it than this. Our process is ran off the attributes in plan files. We pull them to excel, to run a few formulas on them and then use Visual Basic to create, modify and save the individual drawing off. the drawings consist of 1 nested block that contains most of the drawing. That nested block contains about 30 to 35 dynamic blocks. Using VB and the data from excel, we modify each dynamic block so that the end result is the final drawing. Very fast, no human error unless it was in the initial template setup.

Cool.

I know there was no shot intended. I just figured I'd elaborate on WHY it wasn't a good idea to do so. From my end, anyway. Then that way, people could have both sides of the nesting issue covered and could see which side of the fence they sit on.

[.chad]

I understand completely. I wasn't trying to take a shot at you. I only posted to show both sides on the nesting issue. I agree with you, there must be a purpose for it. I work for a structural engineering firm and we draw precast shop tickets to create beams, girders, columns, etc. So to be able to draw a similar object over & over is the daily grind. We have been able to automate the entire process. That I can't give out but I have a severely edited version of the basic principle. Here is 1 side view of a beam with 3 different end conditions. Trust me there is a lot more to it than this. Our process is ran off the attributes in plan files. We pull them to excel, to run a few formulas on them and then use Visual Basic to create, modify and save the individual drawing off. the drawings consist of 1 nested block that contains most of the drawing. That nested block contains about 30 to 35 dynamic blocks. Using VB and the data from excel, we modify each dynamic block so that the end result is the final drawing. Very fast, no human error unless it was in the initial template setup.

nice block!