Topic: VLR-xref-Reactor

[ChrisCarlson]

Based on the AutoDesk http://help.autodesk.com/view/ACD/2015/ENU/?guid=GUID-E2F57EC0-D78B-438A-A8EC-03F368D8CFD7 :VLR-beginAttach contains 3 different items within a list. I was looking into the 2nd parameter which includes the full path name as a string, however parsing the string seems inefficient, especially when all file names could differ in their length and file format. Does the 3rd parameter (Third parameter is a VLA-object pointing to the drawing database that contains the objects being attached.) contain a name for the "parent" file or just the objects within the drawing?

//Edit
Looked into it more, going with the vlr-commandwill start route. Not a whole lot of documentation on vlr-xref-reactor

[T.Willey]

This might help.

http://www.theswamp.org/index.php?topic=15557.0

[ChrisCarlson]

Thanks, I found going with :vlr-commandended I was able to get the xref name with

Code - Auto/Visual Lisp: [Select]

1. (vlax-ename->vla-object (ssname (ssget "_L") 0))

instead of fussing with setting current layer I just have it changing the layer of the xref.

[T.Willey]

That is what the code does.  I think there was an issue if one attached more than one xref at a time, that is why I wrote the routine the way I did.  With your code, only the last xref will change layers.  It was written a long time ago, but should still work.  Glad you found something that works for you.

[BlackBox]

If you're after XREF-specific information during an attach, then look more closely at what Tim's offered.

If all you're after is to ensure that the attached XREFs are placed on the appropriate layer, then simply register a CommandWillStart event handler, and when it is raised, register the appropriate CommandCancelled, CommandEnded, and CommandFailed event handlers, store the current layer, check-set the desired layer, and all XREFs will be automagically placed on the appropriate layer. When either of the CommandCancelled, CommandEnded, and CommandFailed event handlers are raised, first unregister each of them, and then restore your previously stored layer.

As example, here's an old post, that does a bit more than you're attempting here.

Cheers

[ChrisCarlson]

I did peruse that thread and gained some insight but the problem was naming the xref layer the name of the xref. From what I learned or know the xref is not a "AcDbBlockReference" until it's successfully inserted into the drawing.

The thought process I had was to only fire the reactor on vlr-commandended as I would know the attach command finished successfully.

Code - Auto/Visual Lisp: [Select]

1.  (vlr-command-reactor nil '((:vlr-commandended . xr_func)) )

Are you saying that changing the clayer before insert, attaching the xref and changing the clayer back is more efficient than only changing the layer of the xref with vlax-put?

[BlackBox]

I did peruse that thread and gained some insight but the problem was naming the xref layer the name of the xref. From what I learned or know the xref is not a "AcDbBlockReference" until it's successfully inserted into the drawing.

The thought process I had was to only fire the reactor on vlr-commandended as I would know the attach command finished successfully.

Code - Auto/Visual Lisp: [Select]

1.  (vlr-command-reactor nil '((:vlr-commandended . xr_func)) )

Are you saying that changing the clayer before insert, attaching the xref and changing the clayer back is more efficient than only changing the layer of the xref with vlax-put?

In all honesty, I'd have to perform a speed test on each methodology to tell you which is truly more efficient, but in terms of simplicity of code... Yes, absolutely.



Here's why... XREFs are attached to CLAYER by default... In order to change an XREF's layer you either:

Have to catch the ObjectIds of XREFs as they being attached, and then process them in CommandEnded, etc. (you cannot open an Object that is already open, you have to modify it's layer after it's properly Closed, and LISP doesn't have direct access to override the Close() Method in .NET API; Tony's got a good sample floating around here for that). Not all steps included here.

Or you simply filter for CommandEnded and then iterate ALL XREFs, and any that do not currently reside on the appropriate layer are modified accordingly.



Just to reiterate, or you store the current layer, change the layer to suite, and use CommandEnded, etc. to restore layer - AutoCAD still does all of the work for you.

Hope this makes (more?) sense.

Cheers

[ChrisCarlson]

Maybe image attach (.tiff/.jpeg) is a simpler animal compared to .dwg xrefs.

Code - Auto/Visual Lisp: [Select]

1. ;Based off http://forums.augi.com/showthread.php?50540-Help-With-Image-Reactor&p=598423&viewfull=1#post598423
2. (vl-load-com)
3. (or xr
4.     (setq xr
5.            (vlr-command-reactor
6.              nil
7.              '((:vlr-commandended . xr_func)
8.                )
9.              ) ;_ end of vlr-command-reactor
10.           ) ;_ end of setq
11.     ) ;_ end of or
12.  
13. (defun xr_func (react cmd / xr_lname xr_nlayer)
14.         (setq   cmd (strcase (car cmd) t))
15.         (cond
16.                 ((wcmatch cmd "*image*")
17.                 (setq   xr_lname        (strcat "z-"(vla-get-name(vlax-ename->vla-object (ssname (ssget "_L") 0))))
18.                                 xr_nlayer       (vla-add(vla-get-layers (vla-get-activedocument (vlax-get-acad-object))) xr_lname)
19.                 ) ;_ end of setq
20.                 (vla-put-color xr_nlayer 250)
21.                 (vla-put-plottable xr_nlayer 0)
22.                 (vlax-put (vlax-ename->vla-object (ssname (ssget "_L") 0)) 'Layer xr_lname)
23.                 )
24.         )
25. )  
26.  

 

[BlackBox]

Maybe image attach (.tiff/.jpeg) is a simpler animal compared to .dwg xrefs.

It's no different at all (in this context)... And the same limitations on selecting only the last reference (as Tim aptly noted above) still holds true.

Given your stated goal of placing each-and-every-single external reference (and image?) you attach, overlay, or underlay within a given drawing on its own, individual layer based on reference's name... You are relegated to either capturing the ObjectIds with one of the various Object, or XREF-specific events, and then post-processing them following a CommandEnded event being raised, or simply iterating all references by defacto following same (as Objects will already be open prior).

Also, not sure how much of this is your idea, or not... By placing each-and-every-single reference on its own layer of same name (what happens when you have same reference name in different file path?), you're effectively taking a really simple task of automagically placing references onto specific layer(s), and making it a complex task... If you have pull in changing that standard (for the lack of a better term, given none of them are standard across drawings per-se), then I'd strongly advise you to consider doing so.

Cheers

[ChrisCarlson]

Actually, I never thought about the issue when attaching numerous xrefs at once. IMAGEATTACH only allows inserting (1) .tiff/.jpg at a time but XATTACH will allow numerous, this indeed could be problematic. 90% of what we do is based on IMAGEATTACH the other 10% is based on XATTACH. In that case changing the layer before insert would be ideal (in terms of length of script) I imagine a semi? simple foreach function to process each xref prior to insertion. I shall dig more into that one.

In regards to multiple xrefs of the same name in different locations, from my understanding you can't have 1+ xrefs of the same name as Autocad will just use the previous definition.

Code - Auto/Visual Lisp: [Select]

1. Command: XATTACH
2. Xref "Drawing1" has already been defined.
3. Using existing definition.
4.  

Standards or the lack there of is a good point, this routine was brought up as more so a "forced" standardization. Previously the layer or the xref was just "Arch-Roof" or "Civil-Utilities" or worse I have seen "XREF" here. I'll have to look more into what universities or other public standards require in terms of naming.

Thanks

[BlackBox]

Actually, I never thought about the issue when attaching numerous xrefs at once. IMAGEATTACH only allows inserting (1) .tiff/.jpg at a time but XATTACH will allow numerous, this indeed could be problematic. 90% of what we do is based on IMAGEATTACH the other 10% is based on XATTACH. In that case changing the layer before insert would be ideal (in terms of length of script) I imagine a semi? simple foreach function to process each xref prior to insertion. I shall dig more into that one.

The methodologies needed are already provided above, and you'll need only work through the implicit tasks... In short, you can ultimately use the same reactor for both, as is demonstrated in my earlier linked post, using a COND statement.

In regards to multiple xrefs of the same name in different locations, from my understanding you can't have 1+ xrefs of the same name as Autocad will just use the previous definition.

Code - Auto/Visual Lisp: [Select]

1. Command: XATTACH
2. Xref "Drawing1" has already been defined.
3. Using existing definition.
4.  

Try using Reference Manager.

Standards or the lack there of is a good point, this routine was brought up as more so a "forced" standardization. Previously the layer or the xref was just "Arch-Roof" or "Civil-Utilities" or worse I have seen "XREF" here. I'll have to look more into what universities or other public standards require in terms of naming.

In standards, the same rule(s) apply... Keep it simple... The more variations of what those reference name-dependent layers are, means more layers to manage within various Layer States, or where VISRETAIN == 1, etc., more management means less time catching the important design aspects that cost you even more time, etc. later in a project's design.

While perhaps simple, as compared to today's BIM, NCS, etc. standards, I would gladly take even "XREF" over a drawing where each-and-every-single reference has its own layer.

Also, for what it's worth... Universities are the last place you should look to gain wisdom, and they have little if any practical knowledge when it comes to real-world production value (my $0.02).

Cheers