Blocks containing a wipeout in AutoCAD 2018 moves the wipeout above other object

[robert.rienE7F2G]

Blocks containing a wipeout in AutoCAD 2018 moves the wipeout above other objects.

I see that there is a patch out there on 2019, but I have the issue on 2018.

This was working fine until a few days ago and we got an update on AUD we are configuring.

Any suggestions would be helpful.

There is nothing wrong with the draw order in the blocks, I have even exploded a block and still have the issue.

The really strange thing is that you can change the draw order of the block (without Editing the Block) by just selecting them, and change to front it looks normal.

Save the file, close the file, open the file it is fine, save and close or even don't save and you back to square one, Wipeout is on top.

I have checked see if this effects my plot and it does just as expected it should.

Hope someone has some idea of what is happening here.

[АлексЮстасу]

From the experience of older versions.

Try rebuilding the block in the editor:
1. Cut everything except Wipeout.
2. Paste back.
3. Save.
Just Draw Order does not order. There is a sequence of inserting elements in the block.

[robert.rienE7F2G]

Thank you for your post, but as I mentioned, there is nothing wrong with the blocks, I have been completely through them and even as you suggested in your post, started completely from scratch, it still returns the same results.

I know 2019 has this issue and that they released a fix for it, I am curious if this started here in 2018.

It just does not make any sense to me that it would be working for months and then all of a sudden it stops.

I am leaning towards SBS, that they changed something in their Plugins.

Again, any ideas are welcome.

[ChicagoLooper]

Try this:
1-In block editor select wipeout and move to back, close editor saving your changes upon exit.
2-Back in modelspace ‘sync’ the block you just edited.

[robert.rienE7F2G]

Thank you for your response. You are correct is your process if that was my issue. However it is not.

The blocks are being drawn in reverse order when I open the file.
It is a programming issue here not a draw order issue.
As I shared with the developers every block in my file is being drawn in reverse order, now I know this sounds like a draw order issue but have you ever had a block with a DRAW Order issue correct is self without having to edit the block by simply selecting it and selecting move to front?
In objects yes, in blocks no way.

That’s way I know it’s not a “Draw Order” issue. It programming.
The program is flipping it backwards on me.

But hey, great advice for those who have the draw order issue.

Thank you.

[АлексЮстасу]

Cut everything except Wipeout, and paste back into the Block Editor - reliably provide a sequence of writing the elements in the file and the sequence of their reading / displaying. So it always worked well.
When Wipeout was moved down with Draw Order, it only worked for a short time.
Perhaps Autodesk in new versions made an exception for Wipeout - for a special sequence of their reading / displaying. I do not know. But it seems to me that it is unlikely.

[ChicagoLooper]

Simply upload a drawing with the faulty block. Your willingness to share the block will show how serious you are  in finding a solution and how committed you are in your belief that your diagnosis is correct.

[robert.rienE7F2G]

Thank you for your post, however my blocks are not faulty so that is no need to do that. Beside this is a for an agency that I am not allowed to share their data with anyone.

This is a software issue, Please see the bug fix in 2019.
It may have started here in 2018.
I would like Autodesk to confirm this.

Thank you again.

[robert.rienE7F2G]

Thank you for your post, please see prior replays, this is not a block issue.

All blocks are Fine and built correctly.
NOT a Block Issue here.

[ChicagoLooper]

---

@robert.rienE7F2G wrote:
Thank you for your post, however my blocks are not faulty ................

---

Haha. If they were NOT faulty you, and everyone else, wouldn't be posting and reading this thread. Obviously, you are NOT serious about resolving this issue and you are not committed to your diagnosis because if you were, you wouldn't need Autodesk to confirm. Why not let someone else concur with your theory? Are you that much better than others on the forum?

[pendean]

Move away from WIPEOUTs in this instance and use a solid fill assigned with RGB color 255,255,255. Works more often (its an old school tip way before wipeouts ever showed up) and better than Wipouts in blocks etc.

You will find WIPEOUTs work best outside of blocks and in some instances XREFs.

As noted by others, this has been an issue for years now, but if you wish to waste your time trying to figure it out, help yourself. It will still fail.

Good luck.

[robert.rienE7F2G]

I like the idea, and I have used that in the past, but have seen issue with that with some plot drivers, I am sure you have as well.

Thank you for your post.

[robert.rienE7F2G · Accepted solution]

We found the issue, it was a setvar, SORTENTS

it got reset to 0, as soon as it was reset to 127 everything worked once again.

Thank you for your help in trying to figure this out, as I had mentioned it was a software issue and not a block issue, so keep this setvar in your black book, it will mess with your blocks big time.

thanks again.