hatch's draw order of dynamic block changes when editing in place xref

[Anonymous]

Hi,

when editing in place an xref that contains an instance  of a dynamic block, it messes up the draw order of any hatches that belongs to the dynamic block. Here the step for reproducing the issue:

1. create a dynamic block with a polyline as border and a hatch (with solid is more evident); be sure that the hatch is under the polyline; save and exit the block definition;
2. put an instance of the dynamic block in a new file, save and exit;
3. open a new file and add as xref the dwg containg the dynamic block;
4. right click on the xref's instance and select edit xref in place;
5. just save (don't need any particolar action to trigger the issue) the exit the editor in place gui;
6. the hatch is above the polyline.

The change in the draw order of the hatch is permanent, it's not just a graphical glitch that a regenall could fix.

To fix the issue:

1. open the xref (not in place);
2. edit the block;
3. manually bring the hatch back;
4. save changes and exit the block editor gui;
5. save xref;
6. reload xref.

Needless to say, it is really a bothering behaviour, because it severely limits my ability to work smartly with xref: either I have to directly open the xref in order to make changes (losing the crossreference between dwgs that I could need), or, after editing in place, I still need to open the xref to fix the draw order of the dynamic block, which squander the advantage of editing in place an xref.

Do you have any suggestion?

[vinodkl]

Hi,

I am not able to replicate this issue on my end. I have attached a etransmit drawing along with the ref, which you can give it a try and see if you're still facing the same issue.

Also do you have the associative option enabled when you hatch with polyline as the object?

Which version of AutoCAD are you using? Do you have the Softwares updated to the latest version?

If possible can you use the free screencast tool from Autodesk to record your screen and share?

[Anonymous]

Hi,

I've opened your file as is and already I see that the red border is under the hatch: it's only half visible

main file opened as is (have not done any change)

I corrected the block definition so that the hatch is now under the border, and the border is fully visible; saved the xref and reload on the main file:

correct the block definition so that the hatch is under the red border (fully visible now)

I then proceeded with what I described in the earlier post:

1. select xref > right click > edit xref in place;
2. just save and exit the gui (it's not necessary to do anything to trigger the issue)

The result is shown below: the hatch is now above the border which is only half visible.

situation after editing in place the xref: the border is under the hatch (only half visible)

To respond to your question:

1. Yes, the hatch is associative with the border (so that the dynamic action only stretches the polyline, but the hatch fit accordingly)
2. I'm using autocad 2018.1.2

[Anonymous]

Did you ever find a solution to this? I have several users experiencing this problem and we would really like to find a solution.

[Anonymous]

nope my friend, I still have no solutions to this problem. I am no able to tell if this issue has been fixed in more recent versions of autocad though, as I am still on autocad 2018

[Anonymous]

Thanks for replying. I can confirm that the issue is still present in 2020. I'm fully updated. 

I put a lot of time into analyzing what was different about blocks that displayed the behavior and those that didn't, and could not come to any conclusions. The drafting work is very consistent, and the error is not.

[alexanderKPNQU]

I am having the same issue now in 2022. Fully updated as well. I hope there is a fix soon.

[richard]

Hi, I've asked this question before and was solved by someone providing me with an autolisp.

It automatically puts all hatches/wipeouts to the back, just type in the command WTB. it it for both the current drawing and the xref.

Saved me so much time doing clean up work.