PDA

View Full Version : How to find out if XRef is nested


irneb
2009-03-27, 03:45 PM
I've been trying this ... there is a 16 bitcode for the 70 DXF group of a BLOCK. According to devhelp this means: "This block is externally dependent".

Now using the 70 group I can get which blocks are xrefs by loganding to 4, and which of those are overlays by loganding to 8. But never is the 16 bit set.

The 32 bit ("This is a resolved external reference, or dependent of an external reference (ignored on input)") is always set for xrefs (unless they're not loaded / resolved).

So, there does not seem to be any way of directly determining if an XRef is a nested attachment. The only way I can see of determining this is by stepping through all other XRefs and checking if one of their internal entities is a BlockRef of this xref. This is way too convoluted, and with large files increadibly slow!

Does anyone know of an easier way? I can't seem to find anything like this in ActiveX either.

icbinr
2009-03-27, 04:24 PM
Maybe I have oversimplified it but it appears that a nested x-ref has a bit code of 36.

4 = This block is an external reference (xref)

32 = This is a resolved external reference, or dependent of an external reference (ignored on input)

((0 . "BLOCK")
(2 . "P4967LOTS01")
(70 . 36)
(10 0.0 0.0 0.0)
(1 . "N:\\DWGS\\4967\\Preliminary Plat\\P4967LOTS01.dwg")
(-2 . <Entity name: -46591bf0>)
)

irneb
2009-03-27, 05:06 PM
Thanks, I've tried that as well ... seems to have 36 bit code even for normal attached / overlaid xrefs ... not nested.

icbinr
2009-03-27, 05:27 PM
Ahhhh.... Yes, the 36 just tells me it's not an Overlay..... 44 would make it an Overlay.

So that wouldn't be a good test to see if it is nested.

Unfortunately this appears to be similar to the problem of only being able to change the type (Overlay or Attach) of an x-ref in the x-ref pallete.

The info has to be in the drawing somewhere but apparently can't be accessed with LISP or ActiveX.

Ed Jobe
2009-03-27, 07:20 PM
If you use the ActiveX api, you can check the IsXref property of BlockRef objects. You would have to loop through each item of a BlockRef, if the item is another BlockRef, check its IsXref property. To check multiple levels, do this recursively.

T.Willey
2009-03-27, 07:27 PM
If you know .Net you can get it easily, but with other languages, it has not be as easy as one would think.

One test could be to see where it is inserted, as with test I think I remember, the nested xref would not tell you where it was inserted.

Found out something interesting, and figured I'd code it up real quick. This will get all the xrefs within the drawing. It will list all the inserts of said xref, and will list the xrefs that are nested within it. At least it did on my small test. It returns a list of list of enames. The first ename is the xref definition. Then next list within that list will be the list of inserts. The next list will be the list of nested block table record for the xrefs that are nested.


(defun GetXrefs (/ tempData tempEnt XrefList)

(while (setq tempData (tblnext "block" (not tempData)))
(if (equal (logand (cdr (assoc 70 tempData)) 4) 4)
(progn
(setq tempEnt (tblobjname "block" (cdr (assoc 2 tempData))))
(setq tempData (entget (cdr (assoc 330 (entget tempEnt)))))
(setq XrefList
(cons
(cons
tempEnt
(
(lambda ( x / InsList NestList )
(foreach i x
(cond
((equal (car i) 331)
(setq InsList (cons (cdr i) InsList))
)
((equal (car i) 332)
(setq NestList (cons (cdr i) NestList))
)
)
)
(list InsList NestList)
)
(member '(102 . "{BLKREFS") tempData)
)
)
XrefList
)
)
)
)
)
XrefList
)



Command: (setq lst (GetXrefs))
((<Entity name: 7ed545c0> nil nil) (<Entity name: 7ed54530> (<Entity name:
7ed54548>) (<Entity name: 7ed545b8>)) (<Entity name: 7ed54500> (<Entity name:
7ed54520>) nil))


No inserts for nested xrefs
(<Entity name: 7ed545c0> nil nil)

One insert, no nested xrefs
(<Entity name: 7ed54500> (<Entity name: 7ed54520>) nil)

One insert, one nested xref
(<Entity name: 7ed54530> (<Entity name: 7ed54548>) (<Entity name: 7ed545b8>))

Hope that all makes sense.

irneb
2009-03-30, 06:40 AM
Thanks guys! I was really hoping it wouldn't be this difficult ... but unfortunately I'll have to it the way T.Willey & Ed Jobe's explained. :cry:

T.Willey
2009-03-30, 04:57 PM
Thanks guys! I was really hoping it wouldn't be this difficult ... but unfortunately I'll have to it the way T.Willey & Ed Jobe's explained. :cry:

The code I posted is simple. It isn't like Ed's idea at all. You only loop through the block table once, and you never loop through the block definition, so it should run pretty quick. Let me know if you don't understand what it is doing.

You're welcome. I learned something new by this also.

irneb
2009-04-01, 06:50 AM
Thanks, works nicely! Not as fast as a simple check (as I was hoping) :cry:. But, :) a lot better than searching through each and every block in the drawing every time I wanted to check!

Although I'd probably place your routine in ACADDOC.LSP and save its result to a global variable ... which would then be available after the drawing opens. Then simply check through the list ... Great! Thanks!