Select ALL causes wrong rotation

[sepp6NPPB]

An interesting "bug" that I just ran across.

Created a dynamic block for radiators and decided to add a rotation parameter at the end.
Added Rotation, added Rotate and then for Select - I entered ALL.
106 objects selected, great done.
Not so fast!
When that is done, it grabs, as part of the selection - ACTIONS.

If I do a crossing window selection of the entire drawing area I only get 100 objects.

When this set of 100 is saved to the rotation action, the rotation parameter is excluded. Only 99 objects are referenced in the action properties.

The result is using Select "ALL" will cause the block to work incorrectly, where as crossing window  select everything does not.
I am not sure why the crossing window does not select the actions and I am also not sure why including those actions in the rotate function causes the stretch function to mess up.

In my mind, you would want the actions to be part of the rotation?
Is the problem that the rotation action is included in the rotation action set? (Not that I could find in further testing).

I could not figure out how to de-select the actions from the the select ALL workflow.
However, when using the crossing window, the Rotate parameter is automatically excluded. 
I am assuming this is because it can't reference itself - but it is NOT excluded when using the select ALL function.
Which leads me to believe that the code that excludes the "self" object is connected to the mouse actions and not the command line functions. 

This post is more of an FYI because I lost over an hour trying to figure it out.
(and more creating this post!)

Using Autocad 2024 on windows 10.

[Libbya · Accepted solution]

Post the block.  

I suspect this is NOT a bug but is more likely the result of operator error.  It is appropriate for select all to include the actions (just like setting BACTIONBARMODE = 0 and using a selection window) and adding stretch actions to the selection set of a rotate action will result in the angle offset of the stretch actions changing by the degrees of rotation.  That is correct behavior.    

The ability to add actions to the selection set of other actions is very useful and very powerful when used appropriately, but can cause issues for anyone doing so without understanding what they are doing.  

[sepp6NPPB]

(I can't know what tone you intended with your answer, but it didn't really leave me with a "hey this guy is trying to help" warm fuzzy feeling, so keep that in mind as you read below. I normally try to de-escalate, but not feeling that way right now).

Thanks for that thoughtful answer that immediately discredits any efforts that I did to prove that it was not "just" operator error. It is the way the software works - either by design or not - and that behavior isn't/wasn't intuitive. 

And I would *THINK* given what I was trying to do, that I wanted to include the stretch actions in the rotation action. The idea was rotate the entire block, including the actions.

BUT if this is really what is going on - that select all includes the actions, and the crossing window does not - then my understanding of how the actions behave / interact is also wrong.**

The Block does what it is told to do.
It's the process of telling the block CORRECTLY what I wanted it to do.

If I use one process - Command line select "all" - I get one result - that is not expected / "bad".
If I use a different process - Crossing window, that includes the actions in the window, I get a different result.

And the real crux is that it was my understanding that a Crossing Window action selected EVERYTHING.
But using command line select "ALL" selects a 'different' everything.

And I also disproved your suggestion, because you didn't.

The BACTIONBARMODE setting does not change the outcome.

I did further testing.

If I delete the action and create it new, the command line select all function finds 105 objects and saves 104 to the action.

If I right-click and create a new action set, or modify, command line select all finds 106 objects and saves 104 to the action.

I am assuming that in the latter case, it is capturing the Action itself.

**As 30+ year user of Acad and a pretty seasoned dynamic block builder, and now that I think back on it, this might have been the cause of many hours of lost work because the block was not doing what I expected when I used the command line. And this was especially true with the rotation parameter.

However, Here's are the blocks for your reference.
If the two on the right work how you expect, then color me dumbfounded.

[sepp6NPPB]

Upon further testing, BACTIONBARMODE changes the result when using the crossing window.

As you noted:

The ability to add actions to the selection set of other actions is very useful and very powerful when used appropriately, but can cause issues for anyone doing so without understanding what they are doing.  

So then the real question is, why is including the actions in the rotate parameter wrong in this case?

Because that is real problem I ran up against in this case.

[Libbya]

I used no tone other than straightforward information.  If you felt bad hearing that neutral and straightforward information, then maybe you read it with the wrong internal filter applied. It is unfortunate that you couldn't see past the imagined tone and absorb the neutral and straightforward information that I already gave to you. I looked at your block and it is exactly as I explained in my last post.  Select ALL includes the actions that are not selectable with a window when BACTIONBARMODE=1 (but are selectable via window when BACTIONBARMODE=0) and adding those actions to the rotation caused the issue. 

Adding a stretch action to a rotate action's selection set causes the stretch action's angle offset to be dynamically altered by the degrees of rotation.  This is normal and correct behavior. 

I could explain the times when adding actions to the selection sets of other actions is useful and explain the times when it isn't, but given your commentary on the tone you imagined my prior post to have, I think it is probably best for me to avoid attempting to help you any further.  If you are particularly interested, I'm sure I've posted all of the pertinent info in the past on this forum and those posts are available to anyone bothering to look.  Good luck.

[sepp6NPPB]

I started my post with the 'disclaimer' because I was quite frustrated and concerned that, despite multiple re-readings of your post, I could not change my mental tone. I apologize for that now. 

You provide information that helped further illuminate the problem, but I still can't understand the underlying logic in how AutoCAD is treating the different elements of the block.
Even after spending more time testing what are now three different objects that must be captured in a specific 'way' to work as one might intuitively expect.
If you have any links to webpages that might help my understanding of this, I would appreciate it very much.

Here are the cases I can think of, where the PARAMETER, GRIP & ACTION are separate objects.

TEST	1	2	3	4	5	6
PARAMETER	ü	ü	ü	r	r	r
GRIP	ü	ü	r	ü	r	ü
ACTION	ü	r	r	ü	ü	r
Total Objects	104	99	97	102	100	97
Works as Expected	r	ü	ü	r	r	r

I made the blocks with BACTIONBARMODE = 0 so that I could clearly tell if the stretch actions were included in the rotation action. (And I still stand by one of my initial issues, (when BACTIONBARMODE = 1), their should STILL Be some kind of indicator that the Actions were selected, which would have immediately indicated that the ACTIONS were included and I could have quickly seen the issue.)

As expected, excluding the PARAMETER from the rotation action causes incorrect results(Test 4,5,6). BUT why does including the stretch ACTION cause the block to work 'incorrectly' (Test 1)?

My way of thinking is that, when I rotate a parameter, all three 'parts' of the parameter should be rotated.
If the Action is rotated, then an array function that is constructed to stretch horizontally, should now rotate vertically. 

What am I missing in the relationship between the three objects?

What are the scenarios where you would to rotate an ACTION without the Parameter?

This is a screen shot from the file, if you don't want to open it:

[libbybapa]

---

@sepp6NPPB wrote:

BUT why does including the stretch ACTION cause the block to work 'incorrectly' (Test 1)?

 I already answered that specific question twice.  When you rotate a stretch action, it dynamically alters the angle offset of the stretch by the degrees of rotation.  If you rotate the parameter also then it adds a double rotation because the angle offset is the angle that the stretch deviates from the angle of the parameter.  It is all good and correct that AutoCAD is set up that way.  If you don't find it intuitive, that's because it is complicated and complicated things aren't intuitive. 

The scenarios where you would want to add the stretch action to the selection set of a rotate action are not common but do come up from time to time.  A good example would be a door that you would like to be able to rotate to various open angles, but you also want the width of the door adjustment to be on the opening.  If you rotate the angle of the door, then you would want the angle offset of the stretch angle to be offset accordingly so that the door does not become skewed when stretched larger or smaller.  

There are bugs in the way some aspects of dynamic blocks are programmed but none of what you have discussed falls under that category.