Mixing Annotative/Symbolic and Physical-Based objects in one dynamic block

[RGrandmaison]

I would like to be able to nest an "annotative" type of behavior in a block...but the majority of the block should NOT behave as an annotative object. Specifically I'm trying to build a window block that has a window tag that will annotatively resize the hexagon tag and the window number attribute inside the symbol, but NOT scale up the actual window. So the block itself cannot be annotative.

I can get the attribute definition to work just fine...but can't see any way to easily get the hexagon symbol to behave in the exact same manner. It's almost as if what I want to do is to have selective elements inside a dynamic block be annotative, but NOT others.

It would really be a wonderful option in dynamic blocks to be able to do just that. Select an object and, just like you can tell text that they're annotative or not, to do so with geometric entities.

Does anyone have a clever methodology for tackling this issue???

[RGrandmaison]

I'll just reply to myself! It was easier than I thought. I tend to think too deeply about stuff and sometimes overthink them. I simply inserted JUST the hexagon symbol, as a an annotative block, into the window dynamic block...and then assigned to it all the annotative scale options I would need to use it for. Presto! It works beautifully now....

errr! I spoke to soon. It seemed to work fine, until additional testing. Now it seems that the attribute, which is clearly identified as annotative inside the block editor and has all the annotation scales associated to it, won't update properly if the annotative scale changes for the drawing.

If I insert a new instance of the block, the annotative text scaling is correct, but the prior inserted ones do not update, though the hexagon does.

(It really should be easier than this!!!)

[Libbya]

Sure you can do that.  Make the hexagon a block.  Define that block as annotative.  Paste it in your main window block.  Place the justification point of your attribute over the basepoint of the nested annotative block.  

[Libbya]

...you posted while I was typing.  Glad you got it figured out.

[Libbya]

It can certainly work as described.  Post the actual block file.

[RGrandmaison]

Now if only I could get the attributes to behave properly.

Seems they're often seen as the weak link in dynamic blocks...problematic.

[RGrandmaison]

Okay. Take a look and see if you can figure out why the heck the window attribute won't scale properly at times. It's almost as if it gets stuck on whatever the last scale was that it was inserted at.

[RGrandmaison]

OK, I think I see how to have it resize the hex symbol now and keep the space between the hex symbol and the window consistent between scales (placing the insertion point off of the hex symbol at the midpoint of the window sill). And that works great for the hex symbol.

But, I don't see an easy way to keep the window # attdef locked into the center of that hex symbol as the distance is always changing with each different scale use.

There isn't a way to lock an attribute definitions position in relationship to the geometry in a block, is there? So that when that geometry moves, so does the attdef?

[Libbya]

A nested annotative block will scale from its basepoint.  An annotative attribute will scale from its justification point.  If the attribute is part of the nested block it will scale from the block basepoint, but you cannot access the attribute definition.  If you want the attribute accessible and centered in the hexagon, but you want the hexagon to scale from an offset position, I do not believe you will get it to work the way you want.

[RGrandmaison]

The attribute definition is pointless inside a nested block. So, the attribute MUST be an object within the dynamic block and not nested.

I agree that the insert offset for the hexagon block gets me where I need to be for the block scaling to adjust properly- but there's no way to get the attribute to easily behave as simply.

Seems like there needs to be some additional parameters or constraints. One item that is commonly needed to used in the CANNOSCALE plot/scale factor as a simple number for scaling, like 4, 8, 12, 16, 24, 32, etc. There should be an easy way to access this so annotative objects can be placed within a block that is meant to be mostly non-annotative. (Developers, you listening?!?!)

[MMcCall402]

What if you used your hexagon block in a multileader style, then used a field to pull in the value of the attribute.  It would become one annotatively scalable object.

[RGrandmaison]

Hmmmmm...I’ll have to give it a try. I like creative use of objects to get a job done.

I did try to embed the attribute within the hex block and access the attribute value from a field within it, but that never evaluated and updated. It’s as if the block simply can’t reach forward for the attribute since it’s nested- if that makes any sense.

[Joel_Facet]

One option you could do, which I use is quite often, is to just add a point/move action set to the AttDef. If you keep the point on the text justification, its just a quick drag and snap back to the center of the hexagon. yes, it adds one extra step to the use of the block itself, but its a quick step none the less. This way you can keep the annotative capabilities of all desired points of the block, and easily justify the text within.

[MMcCall402]

If you don't lock the position of an attribute I believe the attribute's insertion point grip becomes visible in the block which allows you to move it.