Annotative Block - "Selective" Scale

Is it possible to create Annotative Block with entities that do not react on change of Annotation Scale ?
It would be great to have separete Annotative_Scale_Control for each entity inside Annotative Block, so chosen ones do correspond to change of Annotation Scale, the rest do not.

The same question from different point of view: why limiting Annotative Property to Text, Table, Dimension, Hatch, Leader, Block and Attribute ?
Why not lines, polylines, circles, arcs... ?

Am I asking for too much ? :sad:

An annotative line, arc, or circle makes little sense to me. Why on earth would I want a line to change it's length because I changed the zoom level? And which end of the line would change?

As to the first part -- I would expect that the level of nested complexity that would entail would leave them pretty unusable. do you have an example of where you want a symbol to change size based on zoom level, but other portions of the symbol do not? I just can't visualize where that would be useful. Not saying it would be useless, just that I can't see it based on your post.

I'm glad to find out there is at least one reply to my post, thank you.
Let me try to explain what I would like to accomplish:
I attached very simplified illustration/interpretation of some hypothetical dynamic block which could have one or two Linear Parameters with Stretch Actions - and that's it from Dynamic part of the story.
Attachment 96077Attachment 96078
Block should include 2 attributes (it's easy to make them Annotative). But as you can see from my attachments, change of CANNOSCALEVALUE should trigger scaling of ATTRIBUTES and a little square around them, together with diagonal line between ATTRIBUTES.
Of course, DBLCLICK on the block instance should invoke _eattedit, so use of nested block is out of the question.
Could it be more simple ?
My logic may be twisted, so is there a way to accomplish all these demands ?

And, yes - one more thing, I managed to accomplish all this using Scale_Parameter inside Dynimc Block definition and VL reactor:
(defun SB_SysVarCh ()
(if (not SB_SysVarCh_Reactor)
(setq SB_SysVarCh_Reactor (vlr-sysvar-reactor nil '((:vlr-sysVarChanged . SB_SysVarCh_Call))))
)
)

but I really don't like messing with All_Editing_Time_Active Reactor, especially when it deals with SysVars, even when it only reads its value.

at this point, i'd just use two blocks -- one annotative for the ATTRIBs, & one dynamic. I don't see any benefit to trying to mash them together.

Annotative objects have two benefits -- they will resize themselves to maintain readability, and B) will ONLY be visible when the scale matches. Neither benefit applies to things that are drawn to real-world sizes.

But you would agree that it would be nice feature for Dynamic Scale Parameter/Action to be able (if you choose so) to react on CANNOSCALEVALUE change ?

Yes, I agree this would be useful. Particularily with Civil objects. Manholes etc. at large maping scales would be nice to have "symbolic" but as you change your scale to a more detailed level then the actual real-world structure size is used. similarily with pipes, single line to double line etc.

The answer seems to be yes, you are asking too much for now. I worked with someone who liked annotative multi-leaders.

If you look at them, the 2 extents: point or arrow and text react to the annotative scale but not the leader(s). It works sometimes but not always.

To test, I added many leaders and circled the positions of the text and the ends of each leader. Then I changed the annotative scale. It yields strange results. For some scale, it was fine but other scales sent the leaders anywhere! It seems to be a good avenue but it's not bulletproof yet.

Attachment 108198

When will we be able to add such a feature to a dynamic block is another question.