Dynamic Callout Block text mask

[Crass]

Hello. I have a graphic issue. In our standard block, we have a line/tag coming off of our detail callout bubble that is intended to underline the first line of text for our view title which is an attdef with a field populated through sheet set manager. Sometimes we need to make this text multiple lines, but whenever we do that, the text goes above the line. No matter what I such as futz with object ordering in block editor I can't get the text below the line. Any ideas? Thanks!

In block editorPlotted (pdf) sheet - The Issue!

[timothy_crouse]

Look inside this file at the View Label block.  It has multilines, bottom of the TAG Tab.

Best Regards

-Tim C.

[MMcCall402]

I've had issues with block objects sometimes not honoring the draw order set within the block and reverting to the order in which the objects were created.  The solution was to recreate the object I wanted on top after the object below.

[Libbya]

Post the block.

[timothy_crouse]

One technique to try:

Open the block in a clean draining

go into the block and Ctrl + X the attrib

then paste it back into the block, then do the same with the line and the linear control.

This will reinitialize the draw order.  I find when dealing with issues like you are explaining that I get better results

rather than using the drawing order commands on the menu.  It appears to do a better job of setting the order in dictionary (I think that is what the file area is called where that info is stored).

Close the block editor > Purge >> Ctrl + S, and Again CTRL + S (hitting it twice clears out garbage).

PRO TIP: Never edit a dynamic block in a working file that contains other dynamic blocks.  There is a block editor bug that appears at random that may duplicate objects inside the block editor.

Give that a try, also posting your block, if possible, would help if you want folks to take a look at it.

Best Regards

-Tim C.

[Crass]

Hi @Libbya - Here you go. Thanks so much for taking a look! While you are at it, there are two other issues that I'm trying to get ironed out with this block.

1. When on a thicker plot lineweight, my leader line shows up thicker than the arrow tip. When I try to shorten it to the arrow base, it throws off the stretch action
2. In the preview some of the attdef objects seem shifted from the location in block editor. It makes me nervous that at some point something may cause these objects to start moving around. 

Maybe you or others have insights on these issues as well? Thanks so much!

[Crass]

Thanks @timothy_crouse - I posted the block. I will try this process though later today.

---

PRO TIP: Never edit a dynamic block in a working file that contains other dynamic blocks.  There is a block editor bug that appears at random that may duplicate objects inside the block editor.

---

Interesting... I think I've actually had this happen before. Does that mean that you would keep each dynamic block for our standard callouts, for example, as a separate file in a folder?

[timothy_crouse]

... I think I've actually had this happen before. Does that mean that you would keep each dynamic block for our standard callouts, for example, as a separate file in a folder?



You have a couple options for control BUT the simplest is to keep the dynamic block as a separate standalone file.



OPTION A - Keep dynamic block as a separate file only edit that file and keep an attribute in the file to set the revision. When you have to do maintenance on the block be sure to update the revision info. That way when you come across it in a file you can determine which version you are looking at. Or you can add a rev suffix to the block name.



OTION B - Keep all the blocks in a single file as a library container but when maintenance is required wblock out the block you need to work on out to a temp directory then after you test it insert and redefine the block bock into the library file. Or again add a rev suffix to the block name.





The issue with redefining dynamic blocks with visstates is that when you redefine them the visstate resets to the default state (this may only happen if there is an attribute in the block, there is an odditiy, just cannot remember the specifics). If all the visstates are to be at the same state it is no big deal. You can use the right click menu or quick select to select all the block instance then use the properties menu to set the visstate of all of them at one time.





Two things I have learned in construction drawings where change orders are expensive:

1. Never release ISSUE FOR CONSTRUCTION drawing sets with dynamic blocks in their initial working state. Think of them more as a building tool to get the objects on the screen faster. Once the line work is correct explode it and paste it back in as a block. This way there is no chance that an error'd visstate can cost a change order. E.g. if a piece of equipment length changes or a door is flipped stuff like that can lead to change orders if those instances are not caught.

2. Never edit a dynamic block in a working drawing, the block editor bug will show up and now you have a lot of work to do to fix things.



Best Regards

-Tim C.

[Libbya]

I don't think I have ever before used a background mask on a multi-line attribute with a line in front of it.  That looks like a bug to me.  Indeed draworder seems to not have any effect.  

I would remove the mask from the attribute and instead add a wipeout that can be dynamically adjusted manually to match the desired mask size.  Without a background mask, the attribute will respect draworder properly, as will the wipeout and line.

To fix the leader tip issue, use an actual leader within the block.  

Attribute justification sometimes appears wrong.  Usually it corrects itself when plotting. 

[Crass]

Hi @Libbya - Thanks for the response. Finally have some time to look into this. Both of these solutions seem like a lot of work but I will give it a try...

First I need to figure out how to add the wipeout make sure it moves with the text and think about how the size will be adjusted.

Second, in terms of using a leader in the block. I have it set so you can pick arrow, integral, dot, or none. Can I have that option? Through vis states?

This is starting to get complicated but I'll mess with it. Thanks

[Libbya]

Yes, you can use visibility states for the leader tip options.  That's actually what I would consider a very simple and easy to construct dynamic block.  It would probably take me less than 15 minutes to build from scratch.  I have several blocks that have taken several days of work to build.  

[Crass]

Hi @Libbya - I'm sure you are correct. It's one of those things I only do in spurts after a long hiatus so it takes me a lot of relearning even to recall the basics. It's helpful for me to try to "reverse engineer" based on an example. Maybe I will try to find a callout that uses a leader. I assume you'd want to be mindful of the leader style within the block as in if that changed it would affect all the blocks. Correct? Thanks

Two other issues I'm finding:

1) I attempted to make a solid white hatch instead of a wipeout just to keep it consistent with what I've used below the bubble. I've always been told to avoid wipeouts but that may be antiquated thinking. In trying this I am unable to stretch the hatch like I can the wipeout. It just moves instead. I guess I should just go with the wipeout?

2) I'd also like the ability to toggle the wipeout/hatch but I already have a vis state for the arrowhead. I suppose I could create a simulated multiple vis state with lookup like you've demonstrated elsewhere but it just seems like a lot of work.

Ultimately this just feels like a lot of complexity to address a "bug" that forces the bmask forward. Oh well. I guess complaining isn't going to solve this. Thanks

[Libbya]

If you use the default tip for a given style then I believe that if you change the tip in the leader style then the tip will change for the leader within the block.  If you override the default tip by changing the leader tip in properties then I believe that the change will stick even if you change the tip in the style.  I haven't tested to confirm, though. 

You cannot dynamically stretch just a hatch, but you can create an annotative hatch and dynamically stretch the boundary and the hatch will update to fill the new boundary.  If doing so, I would recommend using a closed polyline as the hatch boundary to reduce the odds that the hatch will lose associativity. 

I have used wipeouts a fair amount in the last decade without issue.  I recall that there were issues years ago with wipeouts plotting black but I have not personally had that issue.  

Adding multiple visibility selection is complicated, but once you have it figured out it isn't hard to implement.  3 leader types and wipeout on/off would require 6 visibility states, two single lookups (one for selection of leader tip and the other for wipeout on/off), one point parameter to house the memory of those selections, and one double lookup to switch the visibility state based on the point parameter's position.