Major wipeout issues in 2019

[JamesMaeding]

Our company switched to version 2019 last week, to celebrate version 2020 being released 🙂

I'm kind of glad I waited, as it only took a week for a major bug to reveal itself.

What we are seeing is wipeouts jump to the front randomly, and they keep doing it even if we remask them.

We have the latest update, 2019.1.2 installed, as well as some machines with 2019.0.1 update only, and same issue.

I call it as major bug as its hard to catch and affects your final plotted product.

You can open the attached drawing in 2018 and 2019 to see the green notes at upper right get hidden.

Erasing various things makes the problem go away. I tried many things to see if there was some pattern. I could not establish any. This might be the first time I have gone back a version after a rollout as 2018 behaves.

I also noticed 2019 does not allow hardware acceleration on some of our fairly new workstations. We don't buy high end stations like for gaming, but all cad stuff runs well on them and I am picky about delays.

Anyway, unzip and try the attached sheet in 2018 and 2019 to see the wipeout behavior:

Keep in mind, I have dealt with wipeouts since they were added to acad, so know they have had issues before.

This is much worse than the other versions handled things though. I did a support request so this is my public support request as I'd like o know if others have run into this.

[JamesMaeding]

for anyone testing, I just noticed I have two wipouts on top of eachother where those notes are.

Just erase one, it does not affect anything but may make things confusing. Its accidental.

For fun, put the wipout draw order to back, then the border DO to back, and it looks good right?

Then save and reopen to see it messed up again.

Bricscad V19 does not have the issue so I think the autodesk dwg reading mechanism has a bug.

So much for "trusted dwg". Now its time to emulate the ODA dwg reader to get back to normal.

[BrianBenton]

I've had this issue often which is why I try to avoid wipeouts as much as possible. Ever since AutoCAD 2007 draw order has been unstable. Have you tried putting the wipeout on a locked layer? Can you use the textmask option instead? One place I worked we used a solid hatch pattern for a note background, but hatch has similar draw order issues.

[RobDraw]

---

@JamesMaeding wrote:

Keep in mind, I have dealt with wipeouts since they were added to acad, so know they have had issues before.

---

And you're still using them? Kind of like shooting oneself in the foot, isn't it?

[pendean]

Everyone knows about the issue in R2019, and hoping R2020 is the actual fix. Guess you will find out next year 🙂

In the meantime you know the remedy, you've been around long enough.

[Erense]

I do experience the same behaviour in both 2019 and 2020.

I also don't like using Wipeouts.

Have looked at the XREF Clip function?

Select the XREF, create a new clip boundary for both text's. (You might have to switch from internal to external)

Only thing here is you can only attach 1 clip per xref.

However this does keep the text visible.

See if you can use this instead of the Wipeouts.

[JamesMaeding]

@BrianBenton 

I have not found draworder to be unstable until this 2019 issue.

I absolutely have tracked the past issues, and totally agree you must do certain things certain ways, such as using wblock to bring things to the front. In the past though, say since release 2002, simply saving a drawing did not mess up draw order.

If things did get messed up, it was typically when creating blocks or new stuff that misbehaved, and you went and fixed it and it was good. This 2019 behavior is totally different.

I also tell people to minimize wipeouts, but plansets are crowded these days and they have always been a part of our production. Our LA office bans them, and I consider them a necessary evil since I also do not trust them fully.

 I have a feeling its not just them though. I worry 2019 messes up draw order of other things too and we have not noticed yet.

I am aware of solids, xclips, mtext masks, AEC masks, and pretty much every way of masking since I've been using acad since version 10 in what I consider "clip intensive" production environments. Wipeouts have been the best solution and honestly we would rather switch to bricscad than give them up. That is saying a lot as any new platform will have its issues too, but at least that team will respond to anything critical. I'll see what happens with my support request on this since I have a drawing replicating the issue.

[timothy_crouse]

This has been an issue for a number of releases.  Some folks see it an other do not.

The basic issue is the drawing dictionary gets confused.

The fix is to go into the block and select all the objects except the wipeout and ctrl+X them them from a base point then ctrl+V to put them back and do what eveer house keeping you have to do.  Avoid touching the wipeout during this process, have fun with that :).

The premise is that you need the wipeout not to be the last thing touched inside the block.  Or touched earlier than the object it keeps getting out of drawing order with, eg popping above

You know you are having a confused drawing dic issue when the drawing order operation seems to do noithing to fix the situation.

A very frustrating issue that seems to be aggrevated by windows updates too.

Best Regards

Tim

[JamesMaeding]

@timothy_crouse 

I know what you are talking about, but this is different behavior than ever seen.

I have been doing the wblock/cut paste workarounds forever. This does not involve blocks in the sense you speak of.

Yes, its the dictionary getting messed up it seems. I know that's where draworder stuff is, but it could be that 2019 is not reading it right.

Anyway, the previous workarounds do not always work on the problem I am seeing. That is the fundamental difference from the past. You fix it, and it goes back next open. Audit does not fix it. Troubleshooting drawings is one of my specialties, though as Robdraw pointed out, seems wipeouts are wiping me out this time. I should have known it from the name...

[timothy_crouse]

A co-worker mentioned the same sort of behavior recently after a windows update.

His odd fix was to get things set right while in model space then head back to paper space and the order would

stay.  But if he went back into model space the order would pop out of sequence.  Seems very odd to me.

At that point I would start a clean drawing and use design center to copy the objects, styles and layouts between drawings and see if that would keep it clean.

Good luck.

[JamesMaeding]

@timothy_crouse 

Interesting. I agree on how to clean things, wblock to new drawing.

One thing to note is the Civil Batch Converter of civil3d actually does that and fast.

Its broke in 2018, use the 2019 version. I will have to try my own advice.

Its not a solution or even workaround though for 80 people doing production.

I can open the same drawings in 2018 and get perfect behavior, so that tells me 2019 is simply not reading the dwg correctly.

[illusionistNUGXG]

I’ve tried it out with AutoCAD Mechanical 2018 and 2019 (I don’t have 2020 installed).

The same errors occur with AM ’19 while 2018 works fine.

The MTEXT stays behind the wipeout, even after changing the draw order, save and load again. - just like you said.

However, i was not able to recreate this behaviour without your file.

Copy + paste your objects into a new file - works fine.

Creating new MTEXTs and wipeouts in your file - works fine (at least for the new ones)

It seems that your file contains an undetected error, that 2019 can’t handle - or an old setting, that 2019 doesn’t use (or doesn’t understand) anymore. - just a guess!

Does this error occur only in “old” drawings?

Purging all drawings by recreating all wipeouts could work...

Copying all drawings into new files could work...

...but both ways are nowhere near an acceptable solution to me.

Does this error occur in a new drawing - created with your standard templates?

Then creating a new “clean” template would be the best thing to do. Even without using 2019 - it would be better in the long run, to have drawings without “hidden corruption”.

Does this error occur in a new drawing - created with an unchanged template?

Hmmm, that would be bad.

My assumption: Even if 2019 doesn’t work as intended - the cause of this error may be in the file.

Bla bla bla:

I also encountered an unique error. The mechanical AMEXPLODE was only able to explode one object per usage. No one else was able to recreate this behaviour without using my file.

Using "old" templates can create unexpected behaviour. As far as i know our standard template was created in ~2009...changed and saved as current format several times.