Printing and Plotting

Reply
*Nienberg, Mark
Message 1 of 9 (68 Views)

draworder and x-refs

68 Views, 8 Replies
02-13-2002 06:50 AM
I've found the answer to this question in the online help, but it really
isn't an acceptable solution. The problem occurs when a drawing contains an
x-ref, and the x-ref has objects in it that need to use the draw order to
plot correctly.

In our case, it happens when objects are hatched. They may plot correctly
in the original drawing, but when x-refed into another dwg, the hatch
overwrites the hatch boundary. Of course the boundary was there first,
since the hatch was created from the boundary, so if the objects are plotted
in the order they were created, it won't look right. You need to send the
hatch to the back in order for it to plot correctly. But this will be
ignored when the drawing is xrefed into another one, and the plots will be
wrong.

The online help suggests setting the correct draworder in the xrerf, then
using wblock to make a block out of the original drawing, then inserting
the block as an xref. Of course, this defeats the purpose of an xref
doesn't it? If I follow this procedure, my drawings won't update when the
xref is updated. So what is the practical solution to this? Thanks for any
suggestions.
Mark
*Dotson, Terry W.
Message 2 of 9 (68 Views)

Re: draworder and x-refs

02-13-2002 10:56 AM in reply to: *Nienberg, Mark
Mark Nienberg wrote:

> The problem occurs when a drawing contains an
> x-ref, and the x-ref has objects in it that need to use the draw order to
> plot correctly.

That's because among its many other limitations, the Draworder command
doesn't work AT ALL in drawings that will become xrefs. Avoid it like
the plague, it will only make your life miserable.

(defun C:FLOAT ()
(princ "\nSelect Objects to Float ...")
(setq sset (ssget))
(if sset
(progn
(command "_.COPY" sset "" "0,0,0" "@")
(command "_.ERASE" sset "")
)
)
(princ)
)

If you want more automation, take a look at the object ordering tools
in ToolPac 6.0 from http://www.dotsoft.com.

Good Luck, Terry
Distinguished Contributor
mdemers
Posts: 133
Registered: ‎12-08-2003
Message 3 of 9 (68 Views)

Re:

02-13-2002 09:48 PM in reply to: *Nienberg, Mark
Mark

It is true the draw order dosen't apply to the imported xref. Let's agree that objects will appear in the order in which they were created. Once the drawing to be xrefed is finished we set the order by wblocking out objects and then reinserting them back into the drawing in the desired order (explode, and purge). For instance wblock out your hatching and then wblock your hatch boundary, and reinsert the hatch first then the boudary. Now when the xref is attached the objects will appear in the proper order. It takes a bit more time initially but it saves time if you're xrefing that into multiple drawings. Works for us.
*Lincoln, Rick
Message 4 of 9 (68 Views)

Re:

02-13-2002 10:09 PM in reply to: *Nienberg, Mark
I haven't tested this yet, but instead of wblock, Ive been using COPY WITH
BASE POINT from the Edit pulldown. That in conjunction with LAYER ISOLATE
and LAYER UNISOLATE, I can copy the entities (base oint 0,0 or such), erase
the copied entities, and PASTE the new entities back in. Might save a couple
of steps if it works.

Just another way to skin the cat.

Rick Lincoln
*Nienberg, Mark
Message 5 of 9 (68 Views)

Re: draworder and x-refs

02-14-2002 02:23 AM in reply to: *Nienberg, Mark
Thanks to all who have replied. I take it that you don't use associative
hatching, because if you copy the boundaries, then delete them, then
reinsert them, I imagine the link between the hatching and boundary is lost.
Correct?
Mark
Distinguished Contributor
mdemers
Posts: 133
Registered: ‎12-08-2003
Message 6 of 9 (68 Views)

Re:

02-14-2002 03:32 AM in reply to: *Nienberg, Mark
Mark

This is how we get around this problem. We have 2 objects around hatching. One object is the hatching boundary which is used to create the hatch. We wblock (or copy with basepoint) both the hatching and its boundary so that the associativeness is retained. The second object is a copy of the boundary as is merely inserted last so it appears on top.
*Eloy, Francisco
Message 7 of 9 (68 Views)

Re:

02-15-2002 02:37 AM in reply to: *Nienberg, Mark
I believe that Terry's FLOAT command does that in one step.

Francisco

"Rick Lincoln" wrote in message
news:4B347AB68AEAF17AF930F8C08153928B@in.WebX.maYIadrTaRb...
> I haven't tested this yet, but instead of wblock, Ive been using COPY WITH
> BASE POINT from the Edit pulldown. That in conjunction with LAYER ISOLATE
> and LAYER UNISOLATE, I can copy the entities (base oint 0,0 or such),
erase
> the copied entities, and PASTE the new entities back in. Might save a
couple
> of steps if it works.
>
> Just another way to skin the cat.
>
> Rick Lincoln
>
>
*Kahlert, Matthias
Message 8 of 9 (68 Views)

Re:

02-17-2002 04:48 PM in reply to: *Nienberg, Mark
canon wrote:
>
> Mark
>
> It is true the draw order dosen't apply to the imported xref. Let's
> agree that objects will appear in the order in which they were
> created. Once the drawing to be xrefed is finished we set the order by
> wblocking out objects and then reinserting them back into the drawing
> in the desired order (explode, and purge). For instance wblock out
> your hatching and then wblock your hatch boundary, and reinsert the
> hatch first then the boudary. Now when the xref is attached the
> objects will appear in the proper order. It takes a bit more time
> initially but it saves time if you're xrefing that into multiple
> drawings. Works for us.

This is far too complicated. Simply arrange the order of your elements
with the draworder command, and then wblock out the whole drawing.
("-WBLOCK", choose the same name as the drawing has and overwrite,
"0,0", "ALL") Then close the drawing without saving and reopen -> voila!

Of course this has to be redone after every operation that affects
draworder.

Matthias
*Lincoln, Rick
Message 9 of 9 (68 Views)

Re:

02-17-2002 09:42 PM in reply to: *Nienberg, Mark
I haven't done much coding lately (three or four years), but I don't see
where the layer is isolated or that you're picking all entities on a
particular layer. A simple filter would add that functionality.

Besides, I'm just trying to present another avenue to the same destination.

Rick Lincoln

"Francisco Eloy" wrote in message
news:0BF62332CD168F3913A1DD0DDC03BBD0@in.WebX.maYIadrTaRb...
> I believe that Terry's FLOAT command does that in one step.
>
> Francisco
>
> "Rick Lincoln" wrote in message
> news:4B347AB68AEAF17AF930F8C08153928B@in.WebX.maYIadrTaRb...
> > I haven't tested this yet, but instead of wblock, Ive been using COPY
WITH
> > BASE POINT from the Edit pulldown. That in conjunction with LAYER
ISOLATE
> > and LAYER UNISOLATE, I can copy the entities (base oint 0,0 or such),
> erase
> > the copied entities, and PASTE the new entities back in. Might save a
> couple
> > of steps if it works.
> >
> > Just another way to skin the cat.
> >
> > Rick Lincoln
> >
> >
>
>

You are not logged in.

Log into access your profile, ask and answer questions, share ideas and more. Haven't signed up yet? Register

Announcements
Are you familiar with the Autodesk Expert Elites? The Expert Elite program is made up of customers that help other customers by sharing knowledge and exemplifying an engaging style of collaboration. To learn more, please visit our Expert Elite website.

Need installation help?

Start with some of our most frequented solutions to get help installing your software.

Ask the Community