Topic: Rules of Dynamic Blocks

[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. 

[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.