Topic: Rules of Dynamic Blocks

[whdjr]

#1  Thou shalt include no other actions in thy selection set.


When you add an action to a block select only the parameters and not the actions themselves.  Your block will do strange things when actions work against each other.  To add or remove something from an action simply double click the action.  It may ask you to make another selection box.  Then you are immediately in the 'Add' mode for this action.  Simply select items to add them to the selection set.  To remove items you have to enter R at the command prompt to change to 'Remove' mode.  Then select items to remove and press enter when finished.


Note:  There is a 1% chance you might want to include an action with another action but I've never made a block that needed that case.

[Josh Nieman]

#2  Always ask around if someone already has made a dynamic block that is similar to what you need.... making dynamic blocks sucks.

Ok... I'm joking... half joking.

[ELOQUINTET]

#3 I've found it to be a good practice to have the properties dialog open while creating modifying dynamic blocks so you can see what options are available to you. This may seem like common sense to most but not for all.

[ELOQUINTET]

#4 Layout your parameters and actions together so It's easy to select the objects you need and not the ones you don't and if it is a complicated dynamic block name your parameters and actions so it is easy to decipher what does what later on.

[whdjr]

#4 Layout your parameters and actions together so It's easy to select the objects you need and not the ones you don't and if it is a complicated dynamic block name your parameters and actions so it is easy to decipher what does what later on.

Dan,

I agree with naming your Parameters and Actions logically; however I don't agree with you about laying out your parameters and actions together.  Most of the time when you use an action it will include several other parameters therefore the parameters need to be in place before you start adding actions.  This may be tough to do initially but you will realize the need for doing it this way when you start using a lot of Visibility States and Lookups.

[Kate M]

To add or remove something from an action simply double click the action.  It may ask you to make another selection box.

Although hitting enter will keep the previous selection box. Handy, since you can't see the box while you're in this "modify selection set" command.

[daron]

#6 Use dynamic blocks sparingly as they rename to an unnamed block and are a pain to capture programatically.

[whdjr]

To add or remove something from an action simply double click the action.  It may ask you to make another selection box.

Although hitting enter will keep the previous selection box. Handy, since you can't see the box while you're in this "modify selection set" command.

Thanks for the Tip Kate.  I didn't know that one.  I have cursed many drawings because I had to redraw the selection box.

[whdjr]

#6 Use dynamic blocks sparingly as they rename to an unnamed block and are a pain to capture programatically.

Daron,

They are different.  Now you have to look for an 'effectivename'.  All blocks now have a 'Name' and an 'Effectivename'.

[daron]

Thanks Will. I saw that, just never dived in to try it out.

#6a Don't use a rotate parameter to rotate all block entities within a block. Use the rotate parameter to rotate objects that need to be rotated independently.

[Mr Cory]

Note:  There is a 1% chance you might want to include an action with another action but I've never made a block that needed that case.

If you have a scale action with an independant base point then the scale action needs to be included in the other action selection sets in the block

[Kerry]

Has anyone done a study of the file size changes using dynamic blocks in relation to using conventional blocks ?

.. or the development time/costs in relation to conventional blocks ?

[whdjr]

Has anyone done a study of the file size changes using dynamic blocks in relation to using conventional blocks ?

Kerry,
I've wondered the same thing since we started using them.  I haven't done any official testing however our dwgs are much bigger than they ever have been before (although our current job is a much bigger one).  It only seems natural that the total number of blocks would have to increase drastically.  Take for instance a 3'-0" door.  If I set a rotation param for the door, then insert it at 0 deg..  If I copy it 4 times(total of 5 copies) still at 0 deg but change the rot. params each to 0, 30, 45, 60, and 90 that would technically be 5 different blocks because their properties would all be a little different so AutoCad would have to remember each one individually in the database.  Now do do this over a whole job that may have 300-400 doors.  Now apply that to windows, reference markers, furniture, etc...  The total number of blocks in our files goes through the roof when this occurs.  We are currently working on a High school with 600 doors, 100 windows, over 400 stl columns, 300 rooms, ...  180,000 sf bldg.

.. or the development time/costs in relation to conventional blocks ?

The development time to combine most of extg blocks to new DBs I feel is worth the effort.  The special ones that you don't use all the time but would be 'cool' are the ones that might not be worth the time.

[Mr Cory]

Each time you modify a DB it basically creates a new block for the combo of your para.s purging blocks with the name U*XXX will cut down the file size obviously

*Edit

No i take that back, as Chris N has informed me, its using 'ctrl c' & 'ctrl v' to copy block around the drawing causes this.

[dan19936]

Take for instance a 3'-0" door.  If I set a rotation param for the door, then insert it at 0 deg..  If I copy it 4 times(total of 5 copies) still at 0 deg but change the rot. params each to 0, 30, 45, 60, and 90 that would technically be 5 different blocks because their properties would all be a little different so AutoCad would have to remember each one individually in the database.

Haven't used dynamic blocks yet,  so this may be an ignorant question. But why would rotating a dynamic block be different than rotating a regular block? Or is that because you're having a single dynamic door block alternately showing a 30/45/60/90 swing? (Guess 0 would be a closed door?)

Dan

[tlindell]

If you want to use the rotate parameter to rotate a block from a consistent base point, that would be acceptable for taking out those steps in a commandline process.  I'm not disagreeing with the "rule" or agreeing with it, but it does add an additional level of complexity to the block with little benifit in most situations and it possibly adds an additional block definaition to the file.

These are more like guidelines than rules anyways.  Good practices and habits nonetheless.

Here's one: don't separate the parameter grip(s) from the original parameter points unless there is a really good reason to.  It will help big time when dealing with those flip actions.

Here's another: flip parameters cause all sorts of unexpected thing to happen.  Use them sparingly.

[Mr Cory]

Only add other actions to flips if said actions have angle offsets or negitive distance multipliers, or if its a scale action with an independant base point.  :pissed:

[Shinyhead]

If you edit a dynamic block with hatch entities, when you exit the block editor I have noticed that the hatch will be unupdated in the existing instances of the edited block.  The quickest way to make them display correctly is to close and reopen the drawing.

Also, regarding hatch in dynamic blocks, hatch performs more reliably when you increase the area of the hatch then when you decrease it.  So make the base entities of the DB as small as you reasonably can and you will get more reliable preformance out of them.

[Shinyhead]

Here are a few more oddball things that may help folks.

Sometimes a single entity in a db will simply ignore its visibility state, when that happens it is easiest to delete it and redraw that part of the block and assign its visibility states.

This one is one some of my drafters have tripped over a few times, once you are in block editor, you cant then define an attribute and expect it to work. It needs to be defined before you make the block, or brought in to the block via cut and paste.  If you define the attribute you will find you cant attedit it once the block editor is closed.

[mjfarrell]

Shinyhead

The reason for those newly defined attributes not behaving is explored here:
http://usa.autodesk.com/adsk/servlet/ps/item?siteID=123112&id=7586586&linkID=9240817

The text of which is:
When you attached a visibility parameter to one or more block attributes in a dynamic block, the attributes remained visible.


Solution


This issue occurs if the Lock position in block check box was not selected when the block attribute was created with the ATTDEF command.

To resolve the problem

In the Block Editor, open the block.
Select the affected block attributes and right-click. Click Properties.
In the Properties dialog box, under the Misc section, change the value of the Lock position to Yes.
Close the Block Editor.
Click Accept to save the block definition.
Note: These changes will only affect new insertions of the block. Block references that were inserted prior to this modification will continue to behave incorrectly.

To avoid the problem in the future, you should make sure that the Lock position in block check box is selected when you create a block attribute (see image below).

[Shinyhead]

Actually I was referring to non attribute entities. We have had lines, plines and arcs all ingore visibility states, the attribute issue I have heard about and is a different issue. If you have not had this happen to you be happy about it, as it is downright annoying.

[whdjr]

I have had some of my linework not behave properly and the easiest thing is to erase it and redraw.

[Mr Cory]

About the attribute being copied and pasted, i disagree, i have more problems coping and pasting than i do when i create them in the block editor especially when im using fields, each to their own i guess

[Shinyhead]

My best results are to try and make all the entities (linework, attributes, etc), then issue the block command, then make them dynamic. It just seems to produce more stable results for me.

[mikehaff]

Dynamic blocks inserted with a "Z" scale other than "1" will not display visibility grips.

[chauhuh]

Beware the flip action and multiline attributes.

Block properties tables are the shiz!

[Daniel J. Ellis]

How to keep something centred compared to another object that's being stretched:
While I was trying to search the web for how to do this, I found a lot of replies that were along the lines of "set the distance multiplier to 0.5" and just left it at that.  In an effort to help the next person who has this problem, a complete step by step guide:
1) Add linear parameter;
2) Set the linear parameter to Chain Actions=Yes and adjust the number of grips as desired;
3) Add a stretch action to the linear parameter;
4) Add a move action:
4a) Select your linear parameter;
4b) Select the endpoint of the linear parameter;
4c) Select objects to move;
5) Select the move action and set the Distance Multiplier to 0.5;
6) Test the block
6a) If it doesn't work curse loudly and repeat from step 4;
6b) If it does work pat yourself on the back proudly

dJE

[chauhuh]

Someone asked for more information on my rotating column block so here it is.

http://www.iconeo.net/2016/rotating-dynamic-block/

Covers chain linking, block tables, and distance multipliers.