Announcements
IMPORTANT. Forum in Read Only mode. You can no longer submit new questions or replies. Please read this message for details
Autodesk Architectural Desktop 2007 & Prior
Welcome to Autodesk’s Autodesk Architectural Desktop 2007 & Prior Forums. Share your knowledge, ask questions, and explore popular Autodesk Architectural Desktop 2007 & Prior topics.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Reply
Message 1 of 12
Anonymous
1071 Views, 11 Replies

objrelupdate

Could someone give the technical definition of what objrelupdate does?

Courtney Cooper
zumBrunnen Architect
11 REPLIES 11
Message 2 of 12
Anonymous
in reply to: Anonymous

Aec objects keep relationships with other Aec objects. From time to time
Aec objects 'lose' the strict definition of thier referenced
relationship. So... Objrelupdate refreshes that relationship and restores
it so that objects act as intended where other objects are concerned...
hence... (Obj)(Rel)ationship(Update)

Courtney Cooper wrote:

> Could someone give the technical definition of what objrelupdate does?
>
> Courtney Cooper
> zumBrunnen Architect

Message 3 of 12
Anonymous
in reply to: Anonymous

I was just wondering if this command could be combined w/ REGEN, and if
not, why.

Courtney Cooper
zumBrunnen Architect
Message 4 of 12
Anonymous
in reply to: Anonymous

As i understand it - it is a matematical recalculation of an AEC Object

Ella
Message 5 of 12
Anonymous
in reply to: Anonymous

I suppose that it could... perhaps thru the use of reactors... or thru lisp
and command undefine and redifine.
The lisp code could then run both the Regen and the objrelupdate command.
Very real posiblility.

Courtney Cooper wrote:

> I was just wondering if this command could be combined w/ REGEN, and if
> not, why.
>
> Courtney Cooper
> zumBrunnen Architect
Message 6 of 12
Anonymous
in reply to: Anonymous

The only reason that I can think of for not having them combined is the time
needed to run OBJRELUPDATE. I have my acad.lsp run a full objrelupdate on
open of a file, and while it solves some cleanup issues, it adds 3-10
seconds to the time needed to open a file. If they could increase the speed
of the update then I would incorporate it into regen.

Robert

"Mike Hutchinson" wrote in message
news:3CE2C710.C2E6BC4F@bbsae.com...
> I suppose that it could... perhaps thru the use of reactors... or thru
lisp
> and command undefine and redifine.
> The lisp code could then run both the Regen and the objrelupdate command.
> Very real posiblility.
>
> Courtney Cooper wrote:
>
> > I was just wondering if this command could be combined w/ REGEN, and if
> > not, why.
> >
> > Courtney Cooper
> > zumBrunnen Architect
>
Message 7 of 12
Anonymous
in reply to: Anonymous

As I understand it, this would require re-coding the base ACAD command
REGEN, which I'm sure they're reluctant to do since there are other flavors
of AutoCAD that do not have need of AEC specific functions. As you know ADT
is just an add on for AutoCAD that you happen to buy in a single box and
install with a single installation. Personally, I think it's the Achilles
heel of the program to have so many redundant commands (objrelupdate is just
one of several) but that's another subject.

The flip side is that it's cool that there are so many base ACAD commands
that DO work on AEC objects.

-Brian

"Courtney Cooper" wrote in message
news:9CF6B5F63993691F4C8155C202B0FE65@in.WebX.maYIadrTaRb...
> I was just wondering if this command could be combined w/ REGEN, and if
> not, why.
>
> Courtney Cooper
> zumBrunnen Architect
>
>
Message 8 of 12
Anonymous
in reply to: Anonymous

While it is entirely possible to redefine the REGEN command to do both a
REGEN and OBJRELUPDATE, the better answer is to have a completely new
command that does both. In it's simplest form:

(defun c:oregen (/ cmd *error*)

;;Error handler in case the user
;;gets tired of waiting and cancels
(defun *error* (msg)
(if
(not
(member
msg
'(nil "console break" "Function cancelled" "quit / exit abort")
)
)
(progn
(princ (strcat "\nError #" (itoa (getvar "ERRNO")) ": " msg))
(setvar "ERRNO" 0)
)
)
(setvar "CMDECHO" cmd)
(princ)
)

;;Hide as many of the the ugly
;;command prompts as possible
(setq cmd (getvar "CMDECHO"))
(setvar "CMDECHO" 0)

;;This included dry humor should probably be removed...
(prompt "\nPlease ignore the following prompt that us mere mortals cannot
kill...")
(command "_.OBJRELUPDATE" "")
(command "_.REGEN")
(prompt "\nThank you.")

(*error* nil)
)
--
Bobby C. Jones
www.acadx.com

"Robert Connor" wrote in message
news:63151237F1922BBB61DFB30CC6A8B72D@in.WebX.maYIadrTaRb...
> The only reason that I can think of for not having them combined is the
time
> needed to run OBJRELUPDATE. I have my acad.lsp run a full objrelupdate on
> open of a file, and while it solves some cleanup issues, it adds 3-10
> seconds to the time needed to open a file. If they could increase the
speed
> of the update then I would incorporate it into regen.
>
> Robert
>
> "Mike Hutchinson" wrote in message
> news:3CE2C710.C2E6BC4F@bbsae.com...
> > I suppose that it could... perhaps thru the use of reactors... or thru
> lisp
> > and command undefine and redifine.
> > The lisp code could then run both the Regen and the objrelupdate
command.
> > Very real posiblility.
> >
> > Courtney Cooper wrote:
> >
> > > I was just wondering if this command could be combined w/ REGEN, and
if
> > > not, why.
> > >
> > > Courtney Cooper
> > > zumBrunnen Architect
> >
>
>
Message 9 of 12
Anonymous
in reply to: Anonymous

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
>
>
Message 10 of 12
Anonymous
in reply to: Anonymous

Yes, somebody does care. Thanks for the info.

I use OBJRELUPDATE so often that I made a shortcut for it in my .pgp file.
I've begun to use it much more often than REGEN. I've posted this file to
the CF ng (see "ObjRelUpdateSample")if you'd like to take a look at, and in
case I'm doing something wrong that causes such a demand for OBJRELUPDATE.

Courtney
Message 11 of 12
Anonymous
in reply to: Anonymous

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
> >
> >
>
>
Message 12 of 12
Anonymous
in reply to: Anonymous

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
> > >
> > >
> >
> >
>
>

Can't find what you're looking for? Ask the community or share your knowledge.

Post to forums  

Autodesk Design & Make Report