New XRef Layers Not Detected with VLISP

New XRef Layers Not Detected with VLISP

lfrostZZNMY
Observer Observer
692 Views
6 Replies
Message 1 of 7

New XRef Layers Not Detected with VLISP

lfrostZZNMY
Observer
Observer

Hello all,

 

I'm coming across an "issue" I've not managed to come across over the last several years and looking for some general support or re-education on some nuances regarding the XRef updating/reloading process. Let me explain my scenario first:

 

There is a LSP utility I constructed that allows users to specify what layers they'd like to batch edit through a list of DWG files. This LSP uses VLlisp and calls upon the ObjectDBX shell to maximize efficiency. However, we just came across an issue where we add a layer to the base XRef file and the routine does not recognize the new layer in the DWGs with the nested XRef UNTIL we open all necessary drawings, just save them all, and close.

 

This gives me the impression that the drawings which has the XRef nested within it does not update the layer library/class (apologies for any improper technical lingo here) until a DWG is fully opened. Can anyone confirm this suspicion for me? Does anyone know of a work around WHILE utilizing the ObjectDBX shell?

 

At this moment, I'm thinking I just need to add a simple open in "foreground" or "background" option for users in such scenarios. But, would obviously love to keep this LSP to a 100% background function to speed through hundreds of drawings in minute or two. (Not saying we need to run this on hundreds of drawings! No, no. Simply testing revealed it could run hundreds of drawings that quickly is all.)

 

 

 

 

Thanks all for your support in advance!

0 Likes
693 Views
6 Replies
Replies (6)
Message 2 of 7

dgorsman
Consultant
Consultant

I'm having a bit of trouble following the process.  Let's see if I have this right:

  1. You use ODBX to batch process DWG files, adding layers to each
  2. You process a different set of drawings using ODBX, which XREF the files with the added layers
  3. The drawings in step 2 don't have the XREF-dependent layers which were added

Is this correct?

----------------------------------
If you are going to fly by the seat of your pants, expect friction burns.
"I don't know" is the beginning of knowledge, not the end.


0 Likes
Message 3 of 7

john.uhden
Mentor
Mentor

@dgorsman 

If what you conjectured is right, then it seems to me that the file with layers added can't expose them to a host without the file having been saved.  That fits with why we must reload an xref.  I believe that AutoCAD warns us that an xref has changed only by checking its date/time.  I don't know how often AutoCAD checks, but I often have the host and the xref opened at the same time, so since both are in the session's documents collection, it makes sense that AutoCAD can pick up the save almost instantly.  I don't recall if there is a delay when someone else has saved the xref.  I work in a small office and most of the time each engineer/tech is working on a separate project.

John F. Uhden

0 Likes
Message 4 of 7

pbejse
Mentor
Mentor

@lfrostZZNMY wrote:

.This gives me the impression that the drawings which has the XRef nested within it does not update the layer library/class (apologies for any improper technical lingo here) until a DWG is fully opened. Can anyone confirm this suspicion for me? Does anyone know of a work around WHILE utilizing the ObjectDBX shell?

I did a quick test on a number of files, I can confirm the strange behavior does exists. What i did is change an xref name and path thru ODBX, The XREF shows the new name and path on Reference Manager but the layers still wont show unless the file is graphically opened the layers does not show. Running Vl-reload XREF item does not update the database.

 

Interesting find @lfrostZZNMY. I never notice it before.

 

Message 5 of 7

lfrostZZNMY
Observer
Observer

@dgorsman : You are correct. The files which are being batched do not possess the layers added within the XREF file itself. Therefore, not appearing in the file being batched.

 

@pbejse & @john.uhden : Thank you for replying. Thanks to you @pbejse for testing yourself!

To be honest, I have no idea how I'm just now noticing myself. I'm sure I've tried this process before and either (a) didn't notice it "failing" before or (b) had the new XREF layers in the state that they needed to be across all my drawings, e.g. turned off/frozen/etc. I suspect the latter (b).

 

Any thoughts how to batch edit in a manner similar to, or with, ObjectDBX? I'd really like not to open and save each drawing unless it is absolutely required. I suspect that it is given my suspicion about when newly added layers are loaded into the drawing - new layers in the XREF are added to the files through some graphical trigger in ACAD.

0 Likes
Message 6 of 7

pbejse
Mentor
Mentor

@lfrostZZNMY wrote:

Any thoughts how to batch edit in a manner similar to, or with, ObjectDBX? I'd really like not to open and save each drawing unless it is absolutely required.


I have yet to try and test that with .NET, Curious if it will behave the same. Publish should work, piggy back a code that saves the file. In theory it should work.---> Publish-Batch-Run-Commands 

 

I'll let you guys know what i will find

 

Cheers

 

0 Likes
Message 7 of 7

lfrostZZNMY
Observer
Observer
GOOD CALL! I actually have a massive LSP plugin for fabrication drawings that piggy backs off of Publishing. That would come in handy if we were ever crunched for time. Thanks for the reminder @pbejse!

The only "concern" there would be that I'd like to be able to save the DWG in the process too - I believe that functionality is possible even during the PUBLISH operation. Just do a (vla-save [curdoc]) syntax. Never experimented with that when piggy backing on the PUBLISH operation. I suspect a save syntax works!
0 Likes