Grips on One Stretch Action are Affected by Another Stretch Action

[sbrusco]

Hi All,

I am finally making headway on the road to implementing dynamic blocks here, so now i have to learn what is necessary and how to create them.

The attached is my earliest attempt at creating a 1/4" bolt whose length is dynamic and the location of the washer and nut is dynamic. If i insert the block, i can use the stretch grip on the length to adjust the length of the bolt, which works fine. Then when i grip stretch the location of the washer and nut, they stretch all right BUT the stretch grip of the bolt length also moves and if i then attempt to adjust the bolt length again...well, it is all wrong.

Please take a look at this "masterpiece" and any help or suggestions will be greatly appreciated.

Sal

[Charles_Shade · Accepted solution]

You're doing fine.

Select Stretch1 and remove the parameter Length from its selection set and it will work as intended.

Housekeeping:

-Excellent work renaming the parameters to something specific. Rename the actions to mimic the parameters too.

-Save/Name the block within the drawing whilst in the BE. You will have a Dynamic Block in a Container drawing. Others will be able to see what your block does without having to do this. (The revised DynBlk is TEST in your file now.)

-The Lookup Table and providing a List for the Length Parameter is redundant.

-Set the Number of Grips for both your parameters to 1. This will remove the caution exclamation and clean up two unused grips in the DynBlk.

[sbrusco]

Thank you Mr Shade,

Your solution was indeed what i was looking for. And thanks for the added "housekeeping tips on which I have a couple comments.

I took your advice and renamed the actions and changed the number of grips to one. Both are good tips.

I left the redundancy of the lookup table and the list on the length parameter so that the user would have the option of stretching the length to one of the available options OR select an avail length from the lookup. I agree that it is redundant but like having the choice at insertion. If i misunderstood you, please give me more details.

And finally, i don't understand what you mean about saving / naming the block inside the BE. Can you please be more specific?

Thanks again,

Sal

[Charles_Shade]

Your drawing was a collection of entities that you assigne dynamic properties to. This is fine to do this way but it requires that someone who may be helping to insert oyur drawing into a new file on thier system as opposed to using your file.

If you save the block within your drawing then the second party can check it within your own file. Its a courtesy. I don;t have it but I suspect that testing your block whil ein the BE does the same thing and therefore would not require the save.

A secondary reason to save the DynBlk within the drawing file is that now you can start to save multiple alike DynBlk's within one file and have quicker access to the whole group whent needed.

[sbrusco]

If you're suggesting that i put similar blocks in the same drawing, as i understand this approach, the users would need to employ the design center to select an individual block from amongst the similar blocks on a block library drawing. I know this is how some work but we prefer to select an individual block from a tool palette. Can this still be achieved with the plan you suggest?

The drawing i attached in the OP was indeed a collection of entities with dynamic properties, intended to be inserted into another drawing. This singular block could be selected from a tool palette OR the design center, which ever the user decides is the best for them.

Am i still missing the point?

[Charles_Shade]

No you're fine in the way you need to do this. Not all solutions work for every situation.

I have some DynBlk's that are not a block in a container drawing as you do and some that are groups of DynBlk's within a container drawing.

Six of one half dozen of another IMHO