AutoCAD 2019 - Wrong color displayed for nested blocks set to ByBlock

[Anonymous]

I noticed that some colors were not displayed correctly in nested block with AutoCAD 2019.

IE:
image.png

Color of all object contained in block 2 is "ByBlock".

image.png

Block 2 is in Layer 1 (red) and color set ByLayer.

2018-11-22 14_51_49-Window.png

All should be red but Block 1 is displayed in blue.

I jointed my example TestByBlock2019.dwg.
The same file is displayed normaly with AutoCAD 2016.

Do you know how to fix this problem?

[cadffm]

Nice catch,

the wrong color is only when color of Block2 is set to "ByLayer", with another color it displays as excpected.

Start a Bug report , open a support case. Adesk should fix this (quickly)

 Tested with ACAD and ACAD LT _VERNUM = "P.162.0.0 

(and 2013/2018)

[Anonymous]

Does it display correctly if the entities within each block are on layer 0?

[cadffm]

In this case: yes

But that does not change the described error.

I changed the Layer of blockreferenBlock1 to Layer0

and for a real test, i changed the color of blockreferenceBlock2 (on layer1) to color green.

Now it isn't longer refer to the layer-color (because the layer to refer the color would be Layer1=red),

it refer the blockreferenceBlock2 color, as expected.

181123-2.jpg

So the problem appears when the nested blockreference(Block1) is not on layer0,

otherwise the 'ByBlock' color goes wrong.

@Anonymous should start a bug report / support case

[Anonymous]

I agree that it's a bug, I was trying to see if there was a workaround until the bug gets fixed.

[john.vellek]

Hi @Anonymous,

I agree that this is not behaving as one would expect and I see that another specialist has already made the team aware of the issue so they might investigate.

Other than modifying the block definition, I do not have an alternative way to get this to work. I appreciate your patience.

[JDuffy]

I've noticed this same issue recently. Virtually everything I work on uses "by block" for lines within a block to make them show up the color of the layer the block itself is on, so most of our files are not behaving as expected. We need the different components of the block to be on different layers, so moving everything to layer zero is not a fix.  Please let us know when there is a fix. 

Thanks.

[pendean]

That last sentence in the message you are replying to indicates the only choice you have at the moment sadly:

"..Other than modifying the block definition, I do not have an alternative way to get this to work. I appreciate your patience...."

Comeback in a month or three if there are not 2019 patches or hotfixes issues and ask again, assuming Autodesk doesn't wait to issue the fix in AutoCAD2020 next year.

[Anonymous]

I had to skip 2019 because of this issue. Simply too much of our standards are dependent on this feature. I assumed it would be sorted in 2020. I was wrong. Looks like my office will have to skip another year again.

[Alfred.NESWADBA]

Hi,

>> Looks like my office will have to skip another year again

Did you report the bug?

- alfred -

PS: if you are referring to your standards, then please make sure that you don't use A$xxxx as block-names, these are only for copy and paste, but should not be names for structured drawings.

[cadffm]

This concerns a core feature("How BYBLOCK should works") in AutoCAD and still an issue until today.

not solved in 2019.0.1
not solved in 2019.0.2
not solved in 2019.1.0
not solved in 2019.1.1
not solved in 2019.1.2
not solved in 2020.0.0
not solved in 2020.0.1
..
and should I guess how it goes on?
weak performance. First, made a mistake and then unwill to solve this.
It's just one of many examples in the past, but users should not tire of
pointing out poor performance and mistakes.

@natasha.l  What is the current state for this in the AutoDESK waiting-loop (means buglist, the correct internal term is unknown to me)

[cadffm]

Offtopic detail: The MatchProp Preview works with another internal code, because the preview displays

the Blockreference as expected 😁

190812-2.jpg

[natasha.l]

Hello @Anonymous, 

Thank you for posting. 

I will follow up with you all soon on this, when I hear back. 

[natasha.l]

Hello @Anonymous, 

I have received word that, this was fixed for next year's AutoCAD release and has been submitted for the next AutoCAD 2020 update, we do not have a scheduled delivery for this. 

Development has no current plans at the moment to patch AutoCAD 2019 or earlier.

Please "Accept Solution" if a reply or replies have helped resolve the issue or answered your question, to help others in the community.

[cadffm]

---

@cadffm  schrieb:

not solved in 2019.0.1
not solved in 2019.0.2
not solved in 2019.1.0
not solved in 2019.1.1
not solved in 2019.1.2
not solved in 2020.0.0
not solved in 2020.0.1

---

not solved in 2020.1

BUT SOLVED in 2020.1.1 !!

wait some days,

Autodesk has withdrawn the release of the update, but surely it will be available for download the next time.
If you want to have a taste, look into the help [F1]
http://help.autodesk.com/view/ACD/2020/ENU/?guid=AutoCAD_ReleaseNotes_autocad_2020_updates_autocad_2...

I have already reviewed two important points superficially and they seem to have been corrected.

BLOCK - Blocks that include multiple text objects using TrueType fonts now display correctly when scaled.
Display - Nested blocks with layer colors set to the Byblock layer now display the correct colors.

[randy.sherwood]

Make everything "bylayer" and then when you change the color of the layer the objects on that layer will change. 

[cadffm]

If you need ByBlock, bylayer is not a possible workaround (and no solution).

Solved in 2020.1.1 and newer

[nrz13]

@natasha.l 
This still isn't working for me in the 2020.1.2 update.  My thread regarding this issue in 2020 is here.

[nrz13]

@natasha.l 
Specifically, it looks like the solution wasn't carried all the way through.  When LAYLOCKFADECTL is anything higher than "0", the locked layer still doesn't display correctly.  (thanks @cadffm for figuring it out!)