Topic: Block Retrieval

[Uriah]

Here's the scenario that I and my coworkers are trying to resolve. I'm sorry that this is so long, but it seems that this is a very difficult problem to describe. I haven't been very successful describing the problem (as I perceive it) to the folks I work with. Hopefully I'll do better here.

In the construction plans that we create we use xrefs. Lots of xrefs. On the xrefs we use blocks, some big block and some little block -- lots of little blocks. The little blocks have attributes that we use for things like pipe sizes, wire sizes, and notes.

When we turn the plans into drawings, we cut the xrefs up using viewports in paper space, and stick the viewports on pages with title blocks. Then we run an AutoLisp program that finds particular blocks on that drawing, and then the program creates a database of the block attributes. Back in the "old days" it was easy -- you just make a selection set of all the blocks with a particular name and extract the attributes.

However, since xrefs and viewports have come along things have gotten increasingly complicated. There are a LOT of blocks in each "dwg" file that we don't want to find. In order to sift those out, our AutoLisp program has been doing all this stuff:

1. Finding a viewport.
2. Saving the coordinates of the viewport.
3. Binding and exploding the xrefs.
4. Finding the desired blocks inside a polygon defined by the saved coordinates of the viewport.
5. Creating a selection set of those blocks.
6. Repeating this for each viewport.
7. UNDO, UNDO, UNDO, ETC until we get the drawing back to a stable state.

As you can see this is very, VERY cumbersome. To make matters worse, the drawings are getting bigger and bigger, and we tend to have multiple xrefs in a drawing. Frequently the computer will completely crash. Sometimes it even screws up the drawings so much that they have to be "recovered."

There simply HAS to be a better way.


What we need is some mechanism to create, in AutoLisp, a selection set of a particular block that is VISIBLE IN THE CURRENT SPACE. I don't care if the block is inserted directly on the drawing, nested deep in xrefs, in a block, in paper space, in model space, I DON'T CARE, but if it is VISIBLE it needs to wind up in the selection set.

If a block is on a frozen layer, on a layer that isn't displayed, outside a viewport, or not displayed for any reason it should NOT be in the selection set.

This has proven to be very elusive. We've tried the "EATTEXT" method, but it is hard to use in AutoLisp and it gives you all the blocks that are in any xref, visible or not. We've tried getting all the blocks and then checking their coordinates, but the math quickly gets out of hand and it's very hard to compare coordinates in the "universe" to those of the "viewport."

I keep telling myself we're missing something really simple, and I'm hopeful that somebody can point us in the right direction.

I'm also hoping that this will make sense.

Thanks!

Wayne.

[Keith™]

What you are asking sounds like a monumental task .... not impossible, but difficult at best. What you might do is try to entnext through the XREF definition in the drawing (by reading the block table) and compare the location of any blocks with offset vector from the insertion point of the xref, then determine if it is showing in the viewport or not. If it is, grab the values and add them to your list.

Pseudo Code:

Code: [Select]


Select all visible XREFs within the viewport (you should be able to do this programmatically)
For each XREF that is visible in the viewport:
  Grab the insertion point
  Find the block table definition
  entnext through the definition
  Grab each nested block with attributes
  For each nexted block with attributes:
    Grab the insertion point (it will be a relational point to the insertion point of that block)
    Verify if the block is within the viewport bounds by applying the block insertion point to a relative vector from the xref insertion point
    If the block is visible within the viewport, add the values to your list of values.
Go to next block until there are no more blocks
go to next xref until there are no more xrefs.


You should be left with a list of attribute values that are showing within the viewport window.

Note: to determine the vector offset of an object,  simply grab the insertion point of it within the block table. For example you have XREF "A" with a nested block. It will show an insertion point of perhaps (10 . 100.0 250.0 0.0) If you are reading it from the block table this is the vector from the insertion point of the block.

Now your XREF perhaps has an insertion point of (10 . 500.0 300.0 0.0)

You need do nothing more that determine the vector point FROM this point ... i.e.
500.0 + 100.0 = Actual X where the nested block is showing; 300.0 + 250.0 Actual Y; and 0.0 + 0.0 Actual Z or (600.0 550.0 0.0)

Now if this point (600.0 550.0 0.0) is within the viewport, then your block is within the viewport. You would now only need to determine if the layer is visible, which shouldn't be a problem as that is simply a check of the layer state.

Like I said .. not impossible, but difficult to implement correctly if you are not familiar with the way it works.

[CAB]

I think the math does get out of hand when blocks in the xref are rotated, and/ or scaled or the
vport has rotated or altered UCS.

There was a way in ACAD2000 to ssget just like nentsel
(ssget ":N") but they did not support this in ACAD2002+
may have stopped it in 2000i

Now it will be very complicated to do it.

Just thinking out loud here, but you might be able to create a group of parallel lines in the
vp then get the intersection with objects, remove lines & use nentsel [corrected] to pick the objects.
There is a chance that some objects could fall through the cracks but that depends on the size
and shape of the objects you are trying to catch, also the lines used to get the intersections
would affect the detection process.

This assumes that (vl-get-InsertionPoint will pick up the objects within the xref.

Just a wild idea, can't think of anything else at the moment. :sot:

[Amsterdammed]

Cab,

remove lines & use nentget to pick the objects

what to Heck is nentget? I can't find it on the www. Typing error?

Bernd

[Amsterdammed]

Wayne

Since my programming skills are weak I sometimes need to go different ways.

Assuming that xrefs are on insert 0,0,0 ; a rule in our company to make sure you can coordinate different small parts in the BIG picture:

I would make for every xref  a .txt file with the same name as the drawing, parking  there the data (in WCS) of all visible attributes.  This I would save for all dwgs on one dbase location.

Make sure that xrefs are not editable by others.

Than, in the Big picture, when you need to get you BOM per viewport, making a ssgget CW with the VP points to get the xrefs names.

For the xref in xref case, you have run trough the ss to add the nested xrefs to your list dwg files involved in this VP.

Than, one for one, check the data out of the txt files with the VP coordinates.
If you don’t like the math to do so, insert a dummy entity on the Attributes insertion point, using the trans function for UCS-WCS hick ups and check with ssget CW  the dummy entity.

If it is in the VP add the Attrib to your list.
I hope I did not make thinks more confusing with this posting.


Bernd

[CAB]

Cab,

remove lines & use nentget to pick the objects

what to Heck is nentget? I can't find it on the www. Typing error?

Bernd

Sorry it was typo, look up nentsel also see nentselp

 

(nentsel [msg])

The nentsel function prompts the user to select an object. The current Object Snap mode is ignored unless the user specifically requests it. To provide additional support at the Command prompt, nentsel honors keywords defined by a previous call to initget.

[Amsterdammed]

Cab,

I know about the nentsel.

Thanks

Bernd

[CAB]

Do you think the method I outlined is doable? or too many holes to fall through?

[Amsterdammed]

CAB,

The Attributes is what he want to use. So i guess he needs a 100% solution for a Bill of Matirials, at least that is what i understood.

Bernd

[CADaver]

I still think EATTEXT is your best bet.  Use lisp to get viewport coordinates and save them to a file, then use EATTEXT to get ALL attrib's.  Once extracted, use Excel to sort out the coordinates for just those you want.  A multi-step procedure, but doable I think.

[whdjr]

I have two thoughts on this:

1)  I have a program I wrote a while back that physically progresses to each Layout tab and scans each tab and each viewport on each tab and returns in a dialog box which xref shows up on which layout tab and in which viewport.  This tool is rather slow because it has to physically go to each layout tab to read each viewport properly.  If any of this tool would be helpful please let me know.

2)  This sounds like it could be done using ObjectDBX to get the xrefs and attributes; however it would be difficult to determine what was shown in each viewport.

my 2c