Linear Stretch and Att Def Malfunction

[Joel_Facet]

Hey guys,

I have created two incredibly simple blocks. And both are giving me problems I haven't seen before. 

Problem #1 - Linear Stretch

The whole purpose of these blocks is to show the extents of steel and its orientation within a wall. This means it requires 2 key parameter, stretch and rotate. I have tried every possible combination and work around I can think of, and have done this on numerous other blocks (with success). But, when I apply a rotate parameter, it skews the stretch and pulls the block into a funny shape. which, obviously isn't ideal.

Problem #2 - Att Definition

My company keeps all of our common blocks on a tool pallet, for ease of access. So the master .dwg containing all of the pallet-ed blocks typically has preset attributes. i.e. these blocks attributes are set to insert the name of its visibility state as a field definition. This works fine and dandy when inserting and initial use. EXCEPT, after you close and reopen a drawing containing the blocks. This causes the fields to set to "####". I have tried running a regen, regenall, and ATTSYNC. None of these fix the issue.

Any intput would be appreciated, thanks.

ps - the "Steel_Header.dwg" will not contain the attribute definition as it was added to a later rendition of the block in our master.dwg. but the "Steel_Channel" will contain it.

[Libbya · Accepted solution]

In 'steel header', remove the stretch ACTIONS from the rotate action's selection set.  If you rotate the linear parameter that the stretch actions are associated with (you need to for the grip to be in the correct location), then you should not rotate the actions.  

[Libbya]

I cannot replicate your attribute issue.  If I insert a new iteration of the block, the field works fine.  If I close and reopen the drawing with the new insertion, the field still works fine.  Perhaps it is an issue with the definition of the block tool on the palette.  I would try removing it from the palette and recreating the tool from the block definition again.  

[Joel_Facet]

Thanks, I had no idea that the ACTION would have such an impact on the parameters functionality. I have made dozens and dozens of blocks and have never had this issue previously. But I did have an idea that the solution would be more simple than not. Thanks again for another problem solved, Libbya.

As far as the attribute definition goes, I think this may take some tinkering around. it sounds like this problem is only occurring at random, as the rest of our team is not experiencing the issue yet. I will keep updates as a I try and find a solution.

[Libbya]

In some cases it is very useful to include an action in another action's selection set.  In other cases, it will cause problems.  Understanding the effect is important.  If you rotate the parameter and not the action, the direction of the action will also change based on the rotation and the grip will move with the rotation of the parameter.  If you rotate the action but not the parameter (dynamically change the action's angle offset), the direction of the action will change based on the rotation but the grip of the parameter will not rotate because the parameter is not rotated.  If you rotate BOTH the action and the parameter, the direction of the action will change by 2X the rotation skewing it as you have seen.  The following screencast shows all three cases (rotate parameter but not action, rotate action but not parameter, and rotate both).