Multileader block colors

[BWYarger]

I have a road construction ahead sign where I have hatched the background orange (color 30) as a mask since I am using an airphoto for the drawing background.  The block is fine until I try to use it in a multileader, then the hatch color switches to block and I can't read the text.  The block was created on the same layer as it is inserted.  How do I get the orange hatch to show as orange in the multileader block?  See the attached screen shot.

[rkmcswain]

I just quickly repeated what I think you did, and it works fine here in an MLEADER. 

The block is on the right, and the MLEADER on the left.

[BWYarger]

The problem has something to with going to a layout.  The multileader looks fine in the model tab, but in a layout, both in paperspace and model space the hatch changes color to solid black.  It also has to do with the plot styles because when I turn off display plot styles, the colors are fine on the screen.  I tried selecting one that I am sure plots color, the none, and the default acad.ctb and all of them show up black on the screen.  I tried printing it to PDF, and it prints in color, so I have a bit of a workaround, but I would like to see what I am working with.  Any thoughts?

[rkmcswain]

What if you use a truecolor instead of ACI color 30?

It sounds like your STB/CTB is mapping color 30 to a black "pen".

Truecolors are not affected by plot styles.

[BWYarger]

True colors didn't work.  It is an issue with display, and the multileader uses the block without any modifications, so I don't understand why the block is fine but the multileader isn't.  If it were a problem with the CTB files, I would expect the problem to affect the block and the multileaders, and the plots.  The problem is only with multileaders in a layout tab on the screen.

I guess I have found a bug.  Thanks for your help.\

Happy New Year!

[Joe-Bouza]

Have you tried editing the block and explicitly sending the hatch to the back? Making the block dynamic with the leader in it may also avert the display issue?

[CADmgrMike]

I just had this happen to me yesterday on a drawing.

We have a multileader that uses a custom block with a background mask color that doesn't print.

We literally have this multileader in thousands of drawings and it's fine.

Yesterday I copied the multileader from one drawing to another one and the masking all of a sudden became the same color as the layer the multileader was on.

I attached a screen shot of what it typically looks like and also what I'm getting in the one drawing.

Another interesting note is if I place the bad mleader into modelspace, it is fine, but if I show it in a paperspace viewport it is not.

I have my reseller tech support working on this also.

[phil_ferguson_tkg]

Echoing Mike Porter...

Having the same issue.

Any thoughts (aside from...Don't copy/paste multileaders with custom blocks)?

[CADmgrMike]

I've had this happen a couple of times as well as some other users here.

It's not necessarily a copy/paste issue because we copy/paste these objects quite frequently and the issue doesn't always happen.

The only fix that I've found when it happens, is to edit the block in the affected drawing, and place the non-plotting hatch on its own layer.

[Anonymous]

I am having this problem too.  Any discoveries of why this does this yet?  Thanks.

(...Not 10 minutes later of fiddling with my drawing...EUREKA!..a solution..)

Previously my multileader keynotes were doing the same hatch problem as the previous posts.  The block being correct, but when part of a multileader they were changing hatch colors.  

I'm not sure if this will work for you.  I went to my layers and removed all viewport overrides, and it worked!  My leaders were back to normal!

Good Luck, hopefully this works for you.

 I am in Civil 3d 2016.

[troma]

Glad you got worked something out. Overrides can be tricky.
But why are you using a hatch for this mask? Why not just put a wipeout into your block?

[Anonymous]

Because with wipeouts we have had printing problems on some of our primary printers. If we take a plan set to pdf sometimes the wipeouts print black. Company standards went to hatch instead, less problems with prints.

[troma]

Hmm.
So you have a specific colour for the hatch mapped to plot white?
If so, can you set the hatch to be that colour in the block? If you have the color set as ByLayer, the layer viewport overrides can change it. If you set the color specifically, the viewport overrides will have no effect.

[Anonymous]

Yes this is how we have it set up. Our color for white is 8. We have the hatch set to specific color 8, but for some reason the viewport overrides DO affect it. Even though they shouldn't. I can send you a sample of the problem if you would like.

[Anonymous]

This worked for me.

Thank you!

[Anonymous]

I was experiencing this issue today.  I would take the leader with the block from one drawing where it looked as it should and pasted it into another.  After I did this, the hatch would then change to whatever color the block was on...I made sure everything had been purged and there was no other existing data interfering with the block....I thought I was almost stumped until I went into page setup and unchecked "Display Plot Styles". No more problem.

[dkinnearBUV5J]

I just ran into this problem in C3D 2020 working in a drawing from another company.  I tried what people suggested, but the only thing that worked for me was to make a separate layer for the hatch.  As soon as I did that, everything looked as expected.

[lynn_zhang]

Hi @dkinnearBUV5J 

Glad to hear that worked for you and thanks for sharing the solution!🙂

[cdurbin76NDS]

So I've been experiencing the same problems as documented in this thread, as well as in the following AutoCAD forum link:

https://forums.autodesk.com/t5/autocad-forum/multi-leader-callout-display-issue/td-p/6071026

Unfortunately, the "solutions" discussed seem to be work-arounds rather than actual solutions to fixing the bug. Removing viewport overrides isn't always an option, and creating a separate layer for the mask hatch within the block also isn't always a viable solution either.

Exploding the mleader also "fixes" the problem (the now stand-alone block appears correctly) but again, this isn't much of a solution.

Is there an actual fix for this bug in any of the recent releases? 

[edhing]

I have had the same problem without finding a direct solution. I would like to hear from you when you find a real solution. At the moment, the only thing I have been able to do that works like old school, is to draw parallel lines all over the area and use them as a background mask of the required color; the thickness of the lines covers the inner area of the block and works well for solid masks.