XREF Methods for Drawing Border

[Spenner]

You will need to split it up into two different blocks. One that contains your attributed text (the changeable portion) and will be "Inserted" and the other that will contain your border file (the static portion) which will be "xref'd".

You cannot edit attributes through an Xref - the attributed block must be inserted if you expect to be able to edit it.

I think I might be getting a little confused here.

That's how we have it here the drawing boarders set up as one block (ie. A0. A1, A2, A3 & A4), which we will Xref in to the drawing in the paper space.
Then we have the drawing title block as another block which we then insert as a block, but to edit the attributes we need to explode the block

I didnt think you could edit the attributes through an Xref..

[bcgatti]

I think I might be getting a little confused here.

That's how we have it here the drawing boarders set up as one block (ie. A0. A1, A2, A3 & A4), which we will Xref in to the drawing in the paper space.
Then we have the drawing title block as another block which we then insert as a block, but to edit the attributes we need to explode the block

I didnt think you could edit the attributes through an Xref..

Do you have a nested block; that contains your attributed text, in your drawing title block? In other words, are your attribute text elements selectable as individual items in the title block or are they part of a block in that file? They have to be selectable as individual items in the title block file.

[tedg]

I think I might be getting a little confused here.

That's how we have it here the drawing boarders set up as one block (ie. A0. A1, A2, A3 & A4), which we will Xref in to the drawing in the paper space.
Then we have the drawing title block as another block which we then insert as a block, but to edit the attributes we need to explode the block

I didnt think you could edit the attributes through an Xref..

Just to clarify what others have already said....

You have "title block" drawing with editable attributes that contain the common PROJECT information that will show up in all sheets. This drawing is in model space.
The attributes are not "raw attributes" they are part of the block (or could be it's own block for that matter) but they are editable via "ddatte" or whatever you use.

And then...
You have your sheet file drawings (layouts that represent your printable drawings).
The title block drawing gets xreffed into paper space for your layout.
Then you (usually) insert a block (that are just editable block attributes) that are the sheet level information, like sheet number, sheet title, etc.

[revacservice]

Personally I use a block with editable attributes for title blocks, limiting X-references to information that may be used by more than one drawing file and may be amended frequently.

I can see no advantage in X-referencing title blocks as once designed there should be no reason to ammend it unless you intend to move office during the course of a project.

All my Clients standard title blocks are stored in a sub-directory and inserted in drawing files as necessary, If a project required a special title block this is stored with the project files.

Don Smith

[RobertB]

Personally I use a block with editable attributes for title blocks, limiting X-references to information that may be used by more than one drawing file and may be amended frequently.

Don, isn't that the definition of a titleblock?

After all, the linework is shared amongst all the sheets, and items such as submittal date are going to be amended frequently and yet are the same on all sheets in the project. (This is from the AEC perspective.)

I can see no advantage in X-referencing title blocks as once designed there should be no reason to ammend it unless you intend to move office during the course of a project.

This is a bit short-sighted. What happens when you need to change elements of the titleblock across hundreds of sheets due to some change from the client?

Decades of experience has shown me that XRefs are the only way to go. At least in the AEC field.

[revacservice]

I concede that there may be a case to xref title blocks if your involved in say a mining company with hundreds and hundreds of drawings and some clown in management decides to change a logo requiring every drawing to be up dated, but pre CAD in this case not every drawing was ever redrawn.

But in most cases the number of drawings are manageable number for any one particular project once the project name and references are set the only thing that changes drawing to drawing is the title and number scale date etc and once that's entered the only other change is the revision letter/number. So if a master file is set up at the start of a project containing the basic info this can be inserted as a block, end of story.

Another plus of not having the title block as an xref, when sharing files with other companies its one less orphaned file to track down.

Keeping track of x-refed files can become a nightmare, one particular project I am currently involved in the Architects issues each drawing as a zip file, which when expanded forms a subdirectory with that drawing number as a name, this directory contains the drawing file and other sub-directories for its x-refed files, fonts etc. etc. So when I'm issued with a number of drawings each referencing the same file I end up with umpteen copies of every font title block and x-refed file and try and find the latest to update my background is no small task, given that each x-refed file may be a different edition and each drawing is made up of a number of files!

There must be a better way.

Don't get me wrong I like x-referencing but please, please keep it simple and manageable

Don Smith
(alias Victor , I don't believe it, Meldrew)

[Brian C]

We never Xref borders, as I find it too difficult to manage, especially since we email dwgs alot.That way we would have to be sure to attach the borders with the email or bind the borders.

We have an autolisp setup program that inserts the border as a block (with attributes). A dialog box asks for size (A, B, D, project, etc).

If the border has to change, we have another autolisp that replaces the border and reads the old attributes (Title, date, etc) and puts them in the new border.

[TerribleTim]

Wow, I guess there are a few ways to make things more and more complicated.

So, the whole debate about x-refs will rage on until the end of time, or until everyone adopts Revit. But, for those who feel that x-refs are too difficult to manage when sending a drawing to someone I would suggest using the tools Autodesk has given you. There is this really cool tool in AutoCAD called "E-Transmit" that will gather all the drawings, fonts, plot styles, etc of a given file and zip them up for you so that you can send them without having any orphaned drawings or missing font files or whatever. Look into it, it's really handy.

As for the debate about x-ref'ing a title block or inserting it into each sheet as a block. I'm with Rob on this one. We constantly have to change not only the date, but the project phase and a few other items as we move through a project. That stuff needs to be in the x-ref so I don't have to change it on every sheet. The only thing in our title block that is not in the x-ref is the sheet number. EVERYTHING else is in the x-ref. The sheet number is the ONLY thing different on each sheet. Why would there be anything else different on each sheet? As for the drawing scale, that is found below the drawing title, not in the title block info. If there are multiple drawings on a single sheet, it makes even more sense to NOT be in the title block info. Just our way of doing things, but sure makes sense to me. Our average job has about 10 sheets. That doesn't seem like too many. But when you have to open each one and change the same thing, it is way too many. We consistently have jobs with well over 35-40 sheets and some with as many as 50-60 sheets. That is only our sheets, not the full set. When we have to manage all of the sheets for the whole set, the power of x-refs is huge. My advice, if you are confused with x-refs from your consultant, call them and ask about it. Everyone uses a slightly different method and a slightly different structure. But they are always willing to tell you all about their methods.

Now, back to the whole "How do I make it so I don't have to explode it when I insert it" deal. If you have created your attributes as a block in the drawing and then inserted that drawing as a block, you now have a nested block, thus you will have to explode it once to get at the attributes. I have not seen a way around this yet. My advice would be this - place the block with the title block info attributes in your template instead of in a separate drawing. This way you are not inserting another drawing as a block, you are only inserting a block in the current drawing. Also, if the title block info is in your template you won't have to go looking for the drawing containing the attributes every time you need it, it will already be "on location". Templates rule my friends!

[revacservice]

So what happens at my end if say an Architect compiles a CD of a drawing set of say 30 drawings, each x-refing the same drawing file for a project, individually zipping each drawing using this E-transmit function?

Do I then end up with 30 copies of every x-ref, font etc. etc. on my hard drive when I unzip them?

If this is so, there must be a better way.

Don Smith

[Glenn Pope]

So what happens at my end if say an Architect compiles a CD of a drawing set of say 30 drawings, each x-refing the same drawing file for a project, individually zipping each drawing using this E-transmit function?

Do I then end up with 30 copies of every x-ref, font etc. etc. on my hard drive when I unzip them?

If this is so, there must be a better way.

Don Smith

You have the option of having it bind the xrefs or not. If you don't bind them then it will set all the drawing that reference the x-ref to relative path. So as long as the unziped files are kept together then they will find the xref.