AutoCAD 2000/2000i/2002 Archive (Read Only)
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Wishlist Item - XREF w/ Attributes

6 REPLIES 6
Reply
Message 1 of 7
jbryant4
160 Views, 6 Replies

Wishlist Item - XREF w/ Attributes

Big drawback of using XREF's, especially for Title Boxes, is that you have to have a separate block for the Attributes.
Why can't AutoDESK somehow embed Attibute Values into the drawing database (XDATA, etc.) mapped to Attribute Tags on attached XREFS in a drawing. When an XREF with ATTs is attached to a drawing, write the Attribue Values to the drawing Database. When Attribute values are changed, these changes are written to the drawing database. Whenever the drawing is opened, AutoCAD see an XREF, looks within the Drawing database and matched XREF name/Attibute Values/Attribute Tags. Something like this seems feesible and would make it possible to attch XREF withsd Attributes.
Kind of hard to explain, but what do yall think?
6 REPLIES 6
Message 2 of 7
Anonymous
in reply to: jbryant4

I like the idea, it has been on my wishlist for a couple of years now.
Something similar to the way visretain works would be great for me.

-Jason

jbryant4 wrote:
>
> Big drawback of using XREF's, especially for Title Boxes, is that you
> have to have a separate block for the Attributes.
> Why can't AutoDESK somehow embed Attibute Values into the drawing
> database (XDATA, etc.) mapped to Attribute Tags on attached XREFS in a
> drawing. When an XREF with ATTs is attached to a drawing, write the
> Attribue Values to the drawing Database. When Attribute values are
> changed, these changes are written to the drawing database. Whenever
> the drawing is opened, AutoCAD see an XREF, looks within the Drawing
> database and matched XREF name/Attibute Values/Attribute Tags.
> Something like this seems feesible and would make it possible to attch
> XREF withsd Attributes.
> Kind of hard to explain, but what do yall think?
Message 3 of 7
Anonymous
in reply to: jbryant4

Yes, you need to put the information that is
different on each drawing into a block which you insert instead of the xref. So
you may as well ask them to change the block attribute manager to allow updating
of block definations without changing the rotation angle of the inserted blocks
(attributes).

Dave Alexander


style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
Big
drawback of using XREF's, especially for Title Boxes, is that you have to have
a separate block for the Attributes.
Why can't AutoDESK somehow embed
Attibute Values into the drawing database (XDATA, etc.) mapped to Attribute
Tags on attached XREFS in a drawing. When an XREF with ATTs is attached to a
drawing, write the Attribue Values to the drawing Database. When Attribute
values are changed, these changes are written to the drawing database.
Whenever the drawing is opened, AutoCAD see an XREF, looks within the Drawing
database and matched XREF name/Attibute Values/Attribute Tags. Something like
this seems feesible and would make it possible to attch XREF withsd
Attributes.
Kind of hard to explain, but what do yall
think?
Message 4 of 7
Anonymous
in reply to: jbryant4

Have you looked into RTEXT? We load a lot of our
Xref title blocks with RTEXT to populate what we used to do with attributes. The
only title block attributes we now edit manually are the ones in the Xref that
remain the same from sheet to sheet in a project, and the few sheet number
identifiers (Sheet Titles, Sheet Number).

 

One really slick thing about RTEXT is that it will
change itself, even if within an Xref. It's kind of spooky, be
forewarned.

 

Here's some RTEXT code for some of our
information:

 

File:
$(getvar,dwgprefix)$(substr,$(getvar,dwgname),1,$(-,$(strlen,$(getvar,dwgname)),4))-$(getvar,ctab)

Plotted: $(edtime, $(getvar,date),M-D-YY at
H:MM)

By: $(getvar,loginname)

 

The biggest drawback to RTEXT though, is it's not a
basic part of AutoCAD. It's an Express Tool and will show up as a proxy graphic
on machines that don't have the arx. (Okay Terry, this is where you take your
cue for LiveText.)

 

Robert Grandmaison



 


style="PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
Big
drawback of using XREF's, especially for Title Boxes, is that you have to have
a separate block for the Attributes.
Why can't AutoDESK somehow embed
Attibute Values into the drawing database (XDATA, etc.) mapped to Attribute
Tags on attached XREFS in a drawing. When an XREF with ATTs is attached to a
drawing, write the Attribue Values to the drawing Database. When Attribute
values are changed, these changes are written to the drawing database.
Whenever the drawing is opened, AutoCAD see an XREF, looks within the Drawing
database and matched XREF name/Attibute Values/Attribute Tags. Something like
this seems feesible and would make it possible to attch XREF withsd
Attributes.
Kind of hard to explain, but what do yall
think?
Message 5 of 7
Anonymous
in reply to: jbryant4

Of course I've never seen the AutoCAD source code, but I shouldn't think it
needs to be so complicated. If you use (entget) on either a block or an
xref, you'll find they are both classified as "INSERT" objects. The
differences are:

1. You can't explode xrefs;
2. Xrefs can be clipped;
3. Xrefs don't have attributes.

But xrefs reside in the block table, just like blocks. They just have a -1
group code, I think, to mark them as different. So theoretically, I don't
see why allowing xrefs to use the same mechansism for attributes as blocks
should be any big deal for the Autodesk programmers. I think it comes down
to more of a policy decision on Autodesk's part.

Michael Evans

jbryant4 wrote in message
news:f06c8fb.-1@WebX.maYIadrTaRb...
Big drawback of using XREF's, especially for Title Boxes, is that you have
to have a separate block for the Attributes.
Why can't AutoDESK somehow embed Attibute Values into the drawing database
(XDATA, etc.) mapped to Attribute Tags on attached XREFS in a drawing. When
an XREF with ATTs is attached to a drawing, write the Attribue Values to the
drawing Database. When Attribute values are changed, these changes are
written to the drawing database. Whenever the drawing is opened, AutoCAD see
an XREF, looks within the Drawing database and matched XREF name/Attibute
Values/Attribute Tags. Something like this seems feesible and would make it
possible to attch XREF withsd Attributes.
Kind of hard to explain, but what do yall think?
Message 6 of 7
Anonymous
in reply to: jbryant4

Michael,

You explode xrefs by binding them and exploding them once bound.
Xrefs are not the same thing as nested blocks ,,,, you know, if you insert a
block into a drawing with attributes, the graphic information of the block
will update ( or it did before ) but the attribute information remains the
same. So why couldn't the drawing with the xref attached maintain the
attribute information similar to what happens when you insert a block with
attributes using =. I don't think that you would want to edit all the
attributes as this would defeat the purpose of xrefs but there doesn't seem
to be any reason not to create a xref attribute specifically for things like
title blocks.

Dave Alexander
Michael Evans wrote in message
news:EEE9FAA2EDAE74C0E573DFAE1FA9BF41@in.WebX.maYIadrTaRb...
> Of course I've never seen the AutoCAD source code, but I shouldn't think
it
> needs to be so complicated. If you use (entget) on either a block or an
> xref, you'll find they are both classified as "INSERT" objects. The
> differences are:
>
> 1. You can't explode xrefs;
> 2. Xrefs can be clipped;
> 3. Xrefs don't have attributes.
>
> But xrefs reside in the block table, just like blocks. They just have
a -1
> group code, I think, to mark them as different. So theoretically, I don't
> see why allowing xrefs to use the same mechansism for attributes as blocks
> should be any big deal for the Autodesk programmers. I think it comes
down
> to more of a policy decision on Autodesk's part.
>
> Michael Evans
>
> jbryant4 wrote in message
> news:f06c8fb.-1@WebX.maYIadrTaRb...
> Big drawback of using XREF's, especially for Title Boxes, is that you have
> to have a separate block for the Attributes.
> Why can't AutoDESK somehow embed Attibute Values into the drawing database
> (XDATA, etc.) mapped to Attribute Tags on attached XREFS in a drawing.
When
> an XREF with ATTs is attached to a drawing, write the Attribue Values to
the
> drawing Database. When Attribute values are changed, these changes are
> written to the drawing database. Whenever the drawing is opened, AutoCAD
see
> an XREF, looks within the Drawing database and matched XREF name/Attibute
> Values/Attribute Tags. Something like this seems feesible and would make
it
> possible to attch XREF withsd Attributes.
> Kind of hard to explain, but what do yall think?
>
>
Message 7 of 7
Anonymous
in reply to: jbryant4

Dave Alexander wrote in message
news:01CF00C9BCE13621F7B637992489E6B0@in.WebX.maYIadrTaRb...
> Michael,
>
> You explode xrefs by binding them and exploding them once bound.

Right, but as I understand it, the process of binding the xrefs converts
them to blocks. So you are really exploding blocks, not xrefs. And if I
think about it, being able to explode xrefs directly ought to be impossible,
if the idea is to maintain an active link to the referenced drawing.

> there doesn't seem
> to be any reason not to create a xref attribute specifically for things
like
> title blocks.

I agree. While the xref mechanism can and should prevent you from changing
any of the referenced geometry directly in the host file for the reason
given above, there's no reason not to be able to have attribute definition
objects in the referenced file whose values are understood to be changeable
in the host file.

> Michael Evans wrote in message
> news:EEE9FAA2EDAE74C0E573DFAE1FA9BF41@in.WebX.maYIadrTaRb...
> > Of course I've never seen the AutoCAD source code, but I shouldn't think
> it
> > needs to be so complicated. If you use (entget) on either a block or an
> > xref, you'll find they are both classified as "INSERT" objects. The
> > differences are:
> >
> > 1. You can't explode xrefs;
> > 2. Xrefs can be clipped;
> > 3. Xrefs don't have attributes.
> >
> > But xrefs reside in the block table, just like blocks. They just have
> a -1
> > group code, I think, to mark them as different. So theoretically, I
don't
> > see why allowing xrefs to use the same mechansism for attributes as
blocks
> > should be any big deal for the Autodesk programmers. I think it comes
> down
> > to more of a policy decision on Autodesk's part.
> >
> > Michael Evans
> >
> > jbryant4 wrote in message
> > news:f06c8fb.-1@WebX.maYIadrTaRb...
> > Big drawback of using XREF's, especially for Title Boxes, is that you
have
> > to have a separate block for the Attributes.
> > Why can't AutoDESK somehow embed Attibute Values into the drawing
database
> > (XDATA, etc.) mapped to Attribute Tags on attached XREFS in a drawing.
> When
> > an XREF with ATTs is attached to a drawing, write the Attribue Values to
> the
> > drawing Database. When Attribute values are changed, these changes are
> > written to the drawing database. Whenever the drawing is opened, AutoCAD
> see
> > an XREF, looks within the Drawing database and matched XREF
name/Attibute
> > Values/Attribute Tags. Something like this seems feesible and would make
> it
> > possible to attch XREF withsd Attributes.
> > Kind of hard to explain, but what do yall think?
> >
> >
>
>

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

Post to forums  

Autodesk Design & Make Report