entmod on block <xref>

[Gary J. Orr]

Am trying to turn an attached X-ref into an overlay x-ref... But entmod doesn't want to cooperate... I originally had the following in one string, but have broken it up in the following code to help illustrate.

Step 1: - Get entity group codes from a valid block definition - (setq X1 (entget (tblobjname "block" "<blockname>")))

Step 2: - Adds 8 to the current value of the 70 group code to turn it into an overlay - (setq X2 (+ 8 (cdr (assoc 70 X1))))

Step 3: - Substitute the new group code for the old one - (setq X3 (subst (cons 70 X2) (assoc 70 X1) X1)

Step 4: - Modify the entity -
(entmod X3)

Always returns nil (no modification to the entity)

Any suggestions or pointers?

Thanx for your time...

 

[Jason Piercey]

No can do. They only way you can do it (programmatically) is to detach and reattach. Unless this has changed in the past few months.

You can double click on the attach/overlay button in the xref dialog box to change it.

 

[Gary J. Orr]

Jason,

Unfortunately using the Xref manager defeats the purpose of the routine, and attaching a new xref destroys all of the layer and viewport settings. (Unless you can think of a way to attach a new xref and keep all of the settings from the old one??? ;-)

I'm working on a utility that brings users into compliance with certain company standards at the touch of a button (relative path statements for xref's and images, overlay vs attach, a few others...)

Are there any methods that can be employed via vl-*** or vlax-*** that could acomplish the same thing, some sort of *put-property* type of thing?

On this same track, and because you can usually come up with some interesting solutions, do you know where to access the "Hidden" top level path statement for AutoCAD? I know that this doesn't make much sense, so I'll try to explain...

After creating an xref you can change the path statement from a hard coded one to a relative one with something like the following:
If a drawing is in:
N:\12345\dwgs\Arch\sheetdwgname.dwg
and the referenced base plan is in:
N:\12345\dwgs\base\basedwgname.dwg
then the path can be changed to:
...\base\basedwgname.dwg

This works well. With Xref's. It falls a little short with Images. If you open a drawing containing an image by double-clicking on the dwg in Explorer or if you use "File -> Open" it works in all tested instances. It often fails if the drawing is opened by selecting it from the history list in the "File" menu. There are other complications with an image in a "Base" plan that is referenced into a "sheet" file.

Double clicking a dwg file or navigating to one sets a path variable somewhere that is equal to the dwg's current folder. Selecting it from the history list does not. I seem to remember this as an issue from some time back, but can't remember what the context of that specific issue was.

Any ideas on this one?

 

[Jason Piercey]

Jason,

Unfortunately using the Xref manager defeats the purpose of the routine, and attaching a new xref destroys all of the layer and viewport settings. (Unless you can think of a way to attach a new xref and keep all of the settings from the old one??? ;-)

I figured as much, but thought I say it anyway. If I hadn't someone

I'm working on a utility that brings users into compliance with certain company standards at the touch of a button (relative path statements for xref's and images, overlay vs attach, a few others...)

Are there any methods that can be employed via vl-*** or vlax-*** that could acomplish the same thing, some sort of *put-property* type of thing?

Not that I am aware of. I think this would have to fall in the lap of an ARX programmer, which I am not. Owen?, Tony?, Bryon?, Stephan?
Anyone?

On this same track, and because you can usually come up with some interesting solutions, do you know where to access the "Hidden" top level path statement for AutoCAD? I know that this doesn't make much sense, so I'll try to explain...

After creating an xref you can change the path statement from a hard coded one to a relative one with something like the following:
If a drawing is in:
N:\12345\dwgs\Arch\sheetdwgname.dwg
and the referenced base plan is in:
N:\12345\dwgs\base\basedwgname.dwg
then the path can be changed to:
..\base\basedwgname.dwg

I believe that you just need to substitue the full path with the drawing name including the .dwg extension. You can use (vla-put-path) to do this. If anyone knows otherwise, please say so.

This works well. With Xref's. It falls a little short with Images. If you open a drawing containing an image by double-clicking on the dwg in Explorer or if you use "File -> Open" it works in all tested instances. It often fails if the drawing is opened by selecting it from the history list in the "File" menu. There are other complications with an image in a "Base" plan that is referenced into a "sheet" file.

Double clicking a dwg file or navigating to one sets a path variable somewhere that is equal to the dwg's current folder. Selecting it from the history list does not. I seem to remember this as an issue from some time back, but can't remember what the context of that specific issue was.

I am aware of a bug with the MRU (most recently used) list, but don't know the exact specifics of it. You might search this group for previous discussions. I recall Robert Bell mentioning it a few times.

 

[Gary J. Orr]

Oh well, guess that I'll have to rely on the users following company standards for the "overlay" part <cough> <cough>. Of course if they did that I wouldn't need a routine to repair it...
But for Robert...

FWIW, We used relative pathing years ago, and finally came to the conclusion that is was more trouble than it was worth.

I'm a firm believer of try, try again... (imagine how few people would be using ABS and ADT without this motto...) The relative pathing gets tricky and only really works with a ridgid directory structure. Fortunately that battle has already been fought and won by the IT department and therefore makes my life easier. The real trick is keeping a specific depth for directories. If you have a base plan in the Base directory and have anotherbase plan referenced into it:

Let's say for the sake of argument a title block with a key plan referenced into it:
Drawing:
N:\12345\dwgs\base\ttlb.dwg
has keymap reference:
N:\12345\dwgs\base\ttlbkey.dwg
with the path:
...\base\ttlbkey.dwg

While the above relative path seems redundant; go up a folder level (..\), then come back into the same folder (base\), it's one of the keys to making relative paths work...

Now xref:
N:\12345\dwgs\base\ttlb.dwg
into drawing sheet:
N:\12345\dwgs\arch\archsheet.dwg
and you'll find that the dependant X-ref (ttlbkey.dwg) will come along for the ride with a path that's wholly appropriate:
...\base\ttlbkey.dwg

This is working where it's been implemented, unfortunately this is failing (on occassion) with raster images (usually the ones that are x-ref dependant and only in the case of opening the file from the "recent" list).

 

[Gary J. Orr]

Yea, that could get tough.
Of course we try to burn a project to CD when we complete it, then when it comes around for the next remodel/ expansion it goes back to the server as a "new" job in a new directory... Keeps the relative thing working. BTW... Do you have any ideas on the point of "relative" paths from my second post in this thread (worse case scenario we could always bind an xref and solve the need to create relative paths for them when we send required electronic files to our client(s) but I've not found a "bind" option for images and still need to get relative paths working for them):

<snip>
This works well. With Xref's. It falls a little short with Images. If you open a drawing containing an image by double-clicking on the dwg in Explorer or if you use "File -> Open" it works in all tested instances. It often fails if the drawing is opened by selecting it from the history list in the "File" menu. There are other complications with an image in a "Base" plan that is referenced into a "sheet" file.

Double clicking a dwg file or navigating to one sets a path variable somewhere that is equal to the dwg's current folder. Selecting it from the history list does not. I seem to remember this as an issue from some time back, but can't remember what the context of that specific issue was.
<snip>