DRAWORDER never works

[Anonymous]

Hi all,

I have created a block and created a wipeout over it and send it to the back. So, if I insert that block into another drawing it covers everything under it. So far so good. Unfortunately I had to add 3 lines in the drawing. The lines are above the wipeout together with the original drawing. But if you look in time I first drew the original drawing, then the wipeout and as last the 3 forgotten lines.

Whatever I do with the DRAWORDER or the DRAWORDERCTL, if I insert it into another drawing AUTOCAD is not able to remember the draworder. I's inserted with the wipeout but the 3 lines are behind the wipeout.

This is so frustrating. Whatever I do with the draworder, it always uses the original draworder when inserted.

I enclosed a screenshot from both situations. Left the original, right when inserted.

DRAWORDERCTL was originally set to 3 (tried everything)

AUTOCAD Mechanical 2016 (also tested in 2018, same result)

When I look this up I find 10 year old unsolved topics about this. I cannot imagine that this isn't solved after 10 years?!

Hope somebody knows a solution...

[Alfred.NESWADBA]

Hi,

try to use white hatches (type solid, color 255,255,255) instead of wipeouts.

- alfred -

[Anonymous]

If hatches were able to take over the background color (gray in modelspace, white in paperspace) that could be a workaroud.

But it's not a solution. The problem is not the wipeout. It's just very visible with a wipeout but if you for example use thicker multileaders or dimlines, the problem is also visible.

[Anonymous]

I did a new test and drew/copied the 3 lines again, but every time in a new DRAWORDERCTL: 0, 1, 2 & 3.

Doesn't change a thing so DRAWORDERCTL is a fake variable.

I discovered that, when I insert that block into another drawing and I reset the block, the draworder changes to what was intended.

So something tells Autocad to change the draworder in a block right after inserting. If I didn't knew better, I would call that a bug...

[pendean]

Friend, RGB color 255,255,255 prints "invisible" it just look white on screen.

Wipeouts have always had this problem, call it whatever you want, the workaround is to use something else or live with the limitation. R2019 is out but the problem persists sadly. Choice is yours.

Good luck.

[braudpat]

Hello

+1 with Pendean & Alfred !

BUT please use the 254,254,254 RGB color instead of 255,255,255 because sometimes you will get Black areas when plotting to PDF ?!

Regards, Patrice

[Anonymous]

Why is everybody talking about replacing the wipeouts with hatches when I mentioned a couple of times that the problem also exists with other objects, not only with wipeouts. Our drawings have to look the same in modelspace as in in paperspace, so hatches are not an option. Otherwise I shouldn't started this discussion. It's the workaround that I find in all the topics. Maybe that's why Autodesk won't fix this.

So let's change the problem:

The problem occurs also with the backgroundmask from a text object. So no wipeout involved.

[Alfred.NESWADBA]

Hi,

>> Why is everybody talking about replacing the wipeouts with hatches

>> when I mentioned a couple of times that the problem also exists

>> with other objects

Maybe because you wrote: "It's just very visible with a wipeout"

And as multiple readers read you are using wipeouts it's the first idea and they just tried to help!

>> Why is everybody talking about replacing the wipeouts with hatches

Because wipeouts are a performance issue and quite often has issues with draworder

>> Our drawings have to look the same in modelspace as in in paperspace

No problem with white background for modelspace and paperspace.

(SCNR: Even better ....my objects look same in modelspace as well as paperspace as well as paper or PDF! Because I don't need CTB or STB to correct colors for plotting 😉 )

>> The problem occurs also with the backgroundmask from a text

>> object. So no wipeout involved.

To make it possible for us to see the exact behavior please create a screencast (>>>free download<<<) and upload the dwg-file you used in the screencast so we can try the same steps and see if we can recreate the issue.

- alfred -

[Anonymous]

I know everybody is trying to help and I really appreciate it but I don't want this topic to be a copy of so many other topics. 😉

I retested it with hatches in model and paperspace (0,0,0 and 255, 255, 255) and this is the result:

As everybody works with his own personal settings, changing the Modelspace background is also not an option.

[Anonymous]

I created this screencast about it with the original drawing from the first post.

First I select the wipeout and send it to the back.

Then I select 4 lines and bring them to the front.

The 3 lowest lines are copies from the upper one.

I save the drawing and insert is as a block in a new drawing.

As you can see, the 3 copied lines are behind the wipeout.

When I reset the block, the draworder is restored as intended.

[Alfred.NESWADBA]

Hi,

>> I created this screencast about it with the original drawing from the first post

Sorry, I don't see a drawing in your first post ...

Also new information: you are using dynamic blocks.

And therefor please open your first dwg "apbt.dwg" (from the video), start command _LIST and look to the name of the block. This blockname starts with "*U" ... am I correct? Inserting unnamed blocks into another dwg-file is always a bit critical and so the reset block is that what you did and what is needed (and it seems to help you with your hidden objects).

- alfred -

[Anonymous]

Hi Alfred,

There was no screencast in my original post, I just ment that this screencast is made with the drawing that I mentioned in my original post.

When I run the _LIST command I get this info:

Block Name: "AMPBD"
Anonymous Name: "*U6"

I don't know how to change the anonymous name, if that's what you ment?

Thanks

[Alfred.NESWADBA]

Hi,

>> There was no screencast in my original post, I just ment that this

>> screencast is made with the drawing that I mentioned in my original post

I know ... you were referring to a drawing in your first post, but I can't see a dwg-file in your first post.

>> I don't know how to change the anonymous name, if that's what you ment?

At least the important information is that it is an anonymous block. Copying such blocks from one drawing to another one is always critical, therefor I avoid that 100%

And it's not a solution to rename that block, an anonymous block (in reference to dynamic blocks) is always a block which is inserted and then any of the parameters modified, which changes the display of the geometry. More critical: every time you modify that block-definition in some cases you need to "reset the block" and then set the same parameters again, otherwise you have discrepancies. The same happens when you copy (or insert) dynamic blocks from one drawing to another.

Dynamic blocks are great, but there are limits.

HTH, - alfred -

[Anonymous]

I'm not sure I'm following.

We create factorylayouts, so basically, a bunch of machines interconnected with conveyingsystems.

All the machines have standard DWG drawing and most of them are dynamic. As far as I know, all blocks are named.

When I create a line I just insert those machine DWG's as blocks. apbt.dwg is an example of such a machine.

I also never copy them from other layouts, I always insert them.

What can I do to avoid a block being anonymous?

[StephenThomasGrace]

Draworder has never worked when using blocks outside the drawing where they were created.

In order for the wipeouts to work properly, after you create your block, edit it in place.

cut all the entities to the clipboard except the wipeout.

paste them back.

Now the wipeout is the first entity.

save the block.

It will now work wherever you want to use it.

AutoCAD DRAWORDER does not reorder the drawing entitiy data base, just the way they are displayed in the specific drawing you are working in.

This also presents itself when you are trying to make a block that asks for attribute values in a certain order.

hope that helps.

-steve

[Alfred.NESWADBA]

Hi,

>> What can I do to avoid a block being anonymous?

As long as you are using dynamic blocks you can't avoid anonymous blocks.

And copy or insert, the origin of the issue is the same, first you need a "untouched insertion" to edit it's parameters, otherwise (in some cases) you need to reset and reassign the parameter settings.

- alfred -

[MikeKovacik4928]

I use both wipeouts for shapes without arcs and solid 255,255,255 hatches for shapes with arcs.

I do have problems with the draw order, and usually have to redo the draw order after I have finished

the complete view, to get it right.

However it has transformed the look of the drawings from cluttered/difficult to read to crystal clear/easy to read.

Before, it was a case of exploding the blocks and trimming-a major time consuming operation.

I never even knew DRAWORDERCTL existed!

By the looks of it, it wouldn't have made any difference anyway!

/

Michael Kovacik
2d & 3d Autocad and Inventor designer/draughtsman
.
Draughting/Designing (Manufacturing) (31 yrs)
-Drawing Board (3 yrs)
--Cad (28 yrs)
---Cadkey (4 yrs)
---AutoCAD 2d & 3d (16 yrs)
---Inventor (4 yrs)
---Autocad and Inventor Simultaneously (4 years)
---(and recently Autocad/Inventor Customisation)
.
Autodesk Product Design Suite Ultimate 2018
Autocad 2018, Inventor Pro 2018
(personal licensed copy)
.
Johannesburg, South Africa
.
(Impossible only means you haven't
found the solution yet)

[nrz13]

That's not true... I've seen DRAWORDER work correctly on occasion.  Ironically, our solution to fix draw order problems is to put objects in blocks, although they're not being copied to other drawings.  I have seen the issue before where blocks copied into other drawings lose their layer order, though.

I really wish Autodesk would implement a forced layer order like you see in many other programs, such as Photoshop, InDesign, etc.  By default everything could be set to 0 and work the same as it does now (or not work), and then you could force the order of all objects on a layer up or down by using positive or negative integers from the default 0.

[Anonymous]

Hello

Very strange !?

Please check :

SORTENTS = 127
WHIPTHREAD (0/1/2/3) = 1
DRAWORDERCTL (0/1/2/3) = 3
TREEDEPTH = 3020
REGENMODE (0/1) = 1

Regards, Patrice