Lisp to set Xref path

[Opie]

I really must know, what does the VISRETAIN system variable have to do with this? It is for maintaining visual changes to layers contained in xrefs.

[BlackBox]

I really must know, what does the VISRETAIN system variable have to do with this? It is for maintaining visual changes to layers contained in xrefs.

Exactly that, *Detective Angel*.

The OP made no mention of either retaining the reference's present visual settings, or restoring the reference's saved state. This was simply stated as a potential enhancement, as this variable's setting has direct impact on the result of the reloaded xrefs.

More specifically, I made reference to changing visretain while testing the routine, as noted in post #15:

I opened our master line work drawing, and referenced in our master contour drawing (same directory as active drawing), then I referenced all roadway plan sheets (from a separate directory), and proceeded to change the layer of all layers containing *|* to red (only xref layers). Changed visretain=0.

Ran my routine, and walla! only the master contour drawing reloaded [to it's original layer colors].

I hope that my (logical?) reason was not misleading, as modifying the variable is not required, simple worthy of consideration.

Sorry for the confusion, I didn't mean for this to create a subtopic, I assure you.

[tbeaman]

I hate to even tell you, but it detached everything without reloading anything.

I get the drawings from other companies so the saved path doesn't even exist on my machine. I keep saying in the same directory because that is where we put all the xref's at, they would not be located in any other folder on our computers.

When I look at the xref manager all of the xref's are either unloaded or not found or unreferenced. I want it to load the ones that I have, because I may or may not have received all of them.

All of the drawings that I do not have display a saved to path that does not exist. However the drawings that they did send me have a path that is just the drawing name.

Why doesn't autocad load this xref's when it opens the drawing since they are right there in the same folder as the main drawing? That would fix it. Maybe I should be searching this instead.

[tbeaman]

Maybe I am off in left field somewhere and should be approaching this from a different angle. I hate to waste your time.

I am going to keep studying.

[BlackBox]

No worries. I really appreciate your patience with my attempts, and will not continue to hound you. I'm just glad someone here (Cadtag) was able to help you find an acceptable solution.

I am just utterly at a loss as to why this (my) routine will not work for you.

Every attempt I make to replicate your results, ends with my routine succeeding (as planned). I've just attached an external reference from another directory, from an external client, with no path selected, and my routine works.

Cheers!

[tbeaman]

I went to a different computer and when I call up the AutoCAD files it loads the xrefs like it is supposed to. I must have an option turned off on mine. Now I get to do a search for that.

[BlackBox]

This could just be my lack on experience shining through, but there is no AutoCAD setting which loads all xrefs at drawing open (that I know of).

*IF* I am correct, one would require a custom routine which loads when you open a drawing (ACADDOC.lsp?), to do this.

[rkmcswain]

Why doesn't autocad load this xref's when it opens the drawing since they are right there in the same folder as the main drawing? That would fix it. Maybe I should be searching this instead.

Yes! That would be my suggestion.

This could just be my lack on experience shining through, but there is no AutoCAD setting which loads all xrefs at drawing open (that I know of).

*IF* I am correct, one would require a custom routine which loads when you open a drawing (ACADDOC.lsp?), to do this.

Correct, there is no setting. It's built into AutoCAD, that is just how it works.
Check out the User's Guide > Share Data Between Files > Reference Other Drawing Files > Resolve Referenced Drawing Errors

Xrefs are searched for in this order: (BTW: I must have been mistaken earlier, I thought the first two were reversed)

* The original xref path
* Current folder of the host drawing
* Project search paths defined on the Files tab in the Options dialog box and in the PROJECTNAME system variable
* Support search paths defined on the Files tab in the Options dialog box
* Start In folder specified in the Microsoft® Windows® application shortcut 

[BlackBox]

Thanks for the clarification / reminder, RK.

[irneb]

Just a note to RenderMan. Your routine should work fine in most cases. However, it is possible to have xrefs loaded from dwg files which are named differently to the xref block definition's name. Two ways this may have come about:

1. The user used the rename command / right-click on xref in manager and renamed the block ... for whatever purpose (I sometimes do this so I can have 2 versions of the xref with different layer settings).
2. The user's browsed to another file to load the xref from such. I sometimes do this when creating RCPs (or finishes layouts). Makes creating such much less of a chore, since it's just a saveas and rename operation. No need to redo the layer settings (even using layer states is more work) ... usually though I do 1 first so I know (later) that this is the case

If either of those has happened your routine searches for the xref by its block name, not its file name. So if I have Plan-Level1.DWG xreffed as Plan your routine would search for Plan.DWG ... which it will never find.

So instead of using (setq xrefName (vla-get-name x)) ... I'd suggest using something like:

(setq xrefName (vl-filename-base (vla-get-Path x)))

Although that may be undefined if it's unloaded ... oh well! Fortunately for me we never bind ... use eTransmit exclusively.