@Anonymous wrote:
.... I tested your routine, and I guess this is not complete ( Just a partial routine to register the location of blocks in model space?) I can see it is making a temp. offset boundary, but it disappears after. But it is not returning any Block counts. and more over it is taking too much time to end the routine.
....
As I said, it's only to identify which Blocks have their insertion points inside the boundary object. [And it should work with any kind of Offsettable object with area as a boundary -- Polyline, Circle, Ellipse, Spline. It will "function" even with an Arc or unclosed Polyline/Ellipse/Spline, though results may sometimes be incorrect.] It doesn't register their locations, but rather puts them into a selection set variable. You can confirm whether it found the right ones, by [after running it] starting a command such as Move or Copy and typing in:
!insiders
[with the preceding exclamation point] for the object selection. It will select/highlight/grip them, and you can hit Enter to complete the selection and then start Moving/Copying just to see clearly which ones it found, since the nature of the Blocks makes highlighting not obvious enough at certain Block scales or Zoom levels. Then cancel without actually Moving/Copying them.
But you are correct -- it does not proceed past finding them -- it was an attempt to get around the possible errors in finding the right Blocks that some other approaches such as crossing-polygon selection encountered. Code for the counts, etc., exists elsewhere, and if those work better with a list of objects, rather than a selection set, the code could be altered very easily to put them in a list instead.
I do find it curious that some of the Offset boundaries that it uses temporarily appear in the drawing briefly as it's working, but not all of them. It does draw all of them, but some must appear and disappear so instantaneously that they're not noticeable. All of them do disappear afterwards, because their only purpose is to compare areas, to decide whether or not a Block, through whose insertion point one was Offset, is inside the boundary.
As for the time to end it, I find that sometimes the cursor location sits there with the working-on-it symbol still showing, past the time when it's actually finished, but just moving the mouse a little "clears" that back to the regular cursor/crosshairs. So if you run it and just move the mouse around slightly while it's working, you may find it ends more quickly than it sometimes seems to. But it could take unacceptably long with a large number of Blocks, since it goes through an Offset command and an area comparison and an Undoing of the Offset for every Block in the current space. However, a longer time should be acceptable if it finds the right set of Blocks reliably and if other, quicker approaches sometimes don't [I'm not suggesting that all of the others on this thread will sometimes get it wrong, since I haven't tried them].
One last consideration -- for Polylines or Splines with certain kinds of convolutions in their shapes, Offsetting even outward can result in more than one new Polyline, such as here, with the sharp-cornered inner of the two larger Polylines as the selected boundary object:

If a Block's insertion point were on that small skinny wedge shape, Offsetting through that would give this result. Then if that wedge, and not the bigger outside one, turned out to be the last object in the drawing, then its area would be compared to that of the original Polyline, and it's obviously smaller, so the routine would think the Block was inside the original. That's one circumstance I can think of in which it could give incorrect results, if you would ever have boundaries with that kind of convolution.
Kent Cooper, AIA