Okay, time to retract my remarks. I've changed our setting for Xloadctl to
"0" and now have proper cleanups upon opening the file(s). The wipeout draw
order issue was fixed by detaching the xref and reattaching "after" the
wipeout objects.
So I was wrong. The registry hack does not seem to be necessary at this
point. I changed it back to "0" and got proper results.
Thanks to the pnCadmanager group for opening up a discussion on Xloadctl!
Steve
"Steve Stafford" wrote in message
news:48B0652946D4008DBF51D261A2B14856@in.WebX.maYIadrTaRb...
> Jim,
>
> I have a project that comprises four buildings, three existing and a new
> addition that joins all three. Each bldg is it's own file as well as each
> floor. A master floor plan then references each exg bldg and all the
> addition is native to this file. I have made the registry change on my PC
> and never get cleanup upon opening these master plans. On the other hand
I
> do get cleanup on files when I open just a native file without xrefs.
>
> So...I'm not convinced that the registry setting is doing anything?
Running
> objre...does fix the files, but since I'm also using a few instances of
> "wipeout" the objre...undoes that and forces me to redo the draworder of
the
> reference files....tedious. at best. I could share the files with you if
> that helps?
>
> Thanks for the "history" lesson!
>
> Steve
>
> "Jim Awe" wrote in message
> news:D71E20B19D6D3DD69777F30DC658549C@in.WebX.maYIadrTaRb...
> > Here is the full history of this command, just in case anyone cares...
> >
> > ADT objects have two traits that "normal" AutoCAD objects don't usually
> > have.
> >
> > 1) Relationships to other objects
> >
> > 2) Multiple graphical representations
> >
> > Because of these, the graphics produced for a single object are
dependent
> on
> > the current state of one or more other objects. When one of the objects
> it
> > depends on changes, appropriate notifications have to go out so that
> > everyone can update themselves. Under normal circumstances, all of the
> > notifications should be correct and all of the objects should get
updated.
> > The system is also optimized to only update when it absolutely has to.
> >
> > OBJRELUPDATE was added as a "debugging" command when we originally
> developed
> > the product. It acts like REGEN in that it forces an update to the
> graphics
> > (and the relationships with other objects) whether the system thinks it
> > needs one or not. We left it in the product as a "backdoor" just in
case
> > some event happened in the system that we didn't get the correct
> > notification for. It turns out that certain conditions of resolving
Wall
> > cleanups in Xrefs caused exactly that problem. This has been the most
> > common reason to use OBJRELUPDATE, but a registry setting is now
available
> > which elimates that need.
> >
> > This is not intended as a command you need to use except in rare
> > circumstances. If anyone comes up with reasons why they consistently
need
> > to use it, please let us know so we can fix the notification problem
that
> is
> > causing things to not be in sync.
> >
> > Jim Awe
> > Autodesk, Inc.
> >
> >
> > "Courtney Cooper" wrote in message
> > news:4D8ADAAF8E28B6019A9C6264BB333163@in.WebX.maYIadrTaRb...
> > > Could someone give the technical definition of what objrelupdate does?
> > >
> > > Courtney Cooper
> > > zumBrunnen Architect
> > >
> > >
> >
> >
>
>