CADForums.net

RaghuMN · Guest

Hi all,

I have 2 entities (point / block / text) at same point.
I know 1 of them and want to select the other leaving out the known one. How can I do that?

This does not work for me.

;get the details of 1 entity (block)
(Setq a (car (entsel))) ;get the 1st entity
(setq det (entget a)) ; details of a
(setq e (cdr (assoc -1 det))) ; entity name
(setq h (cdr (assoc 5 det))) ; handle
(setq i (cdr (assoc 10 det))) ;insertion point

;now try to select the other feature

;tried using handle
(setq oth (ssget "x" (list (cons 0 "insert")(cons 10 i)(cons -4 "<NOT")(cons 5 h)(cons -4 "NOT>"))))

;tried using entity name
(setq oth (ssget "x" (list (cons 0 "insert")(cons 10 i)(cons -4 "<NOT")(cons -1 e)(cons -4 "NOT>"))))

Thanks for any advice.

MNRaghu

Joe Burke · Guest

RaghuMN,

I'm confused. Are you trying to make a selection set containing only a text object
which shares the same insertion point as a block insert?

Joe Burke

RaghuMN · Guest

Joe,
I mean It's of the same entity type.
If there are 2 entities at the same insertion point, both are of same type, i.e., block and block, text and text, etc.

So, I know the handle/entity name of one block at the point where another block resides. I want to catch that another block, leaving the known block.

Hope I have clarified the doubt to some extent.

Thanks,

MNRaghu

Joe Burke · Guest

RaghuMN,

Yes, that helps to clarify the issue.

Let's assume what I suspect is the most difficult case. You have two text objects
which share a common insertion point. The IP of one of the two (call it TEXT1) is
known. You want the other text object (call it TEXT2) to be added to a selection set,
which excludes TEXT1.

There's a fundamental problem with the idea you might be able to use the TEXT1 IP, to
select TEXT2. It will only work if the pickbox covers some part of the TEXT2 object.
And that will be zoom dependant.

IOW, I don't see a way to reliably ssget the TEXT2 object by passing a point, while
excluding the TEXT1 object.

Consider the possibility, the TEXT2 object might also include leading spaces. Which
would in turn make selecting it by point, all the more problematic.

Similar ideas apply to blocks, where the block IP might not be on an object within
the block.

Joe Burke

Allen Johnson · Guest

You can step though the selection set comparing the handles of all the
objects, and then (ssdel) the object that matches the handle of your
original object. You may want to use a crossing window selection set based
upon a certain distance from the insertion point of the original text to
ensure that it finds the other objects. Sort of what Joe Burke was
concerned about.

RaghuMN · Guest

Thanks for the clarifications Joe and Allen.

Gentlemen, hope I have got you correctly, that, using handle and entity name in the ssget function (directly) does not work. Hoping for any shorter solutions in future,

Thanks,

MNRaghu

James Allen · Guest

From help file:
"The ssget function recognizes all group codes except entity names
(group -1), handles (group 5), and xdata codes (groups greater than 1000)."
Sorry. What is your application? Are you deleting duplicate objects?
--
James Allen, EIT
Malicoat-Winslow Engineers, P.C.
Columbia, MO

"RaghuMN" <nospam@address.withheld> wrote in message
news:7922359.1104378857025.JavaMail.jive@jiveforum1.autodesk.com...

RaghuMN · Guest

James, thanks for making the issue more clear.

Yes, my intention was to delete the duplicate objects. I now get the selection set and find the other object if it is not same as the known object using conditional statement.

Thanks,

MNRaghu

James Allen · Guest

You're welcome.

Along the lines of what Allen suggested, would this work for you?

(Setq a (car (entsel))) ;get the 1st entity
(setq det (entget a)) ; details of a
(setq flt det) ; initialize filter
;; remove invalid group codes
(foreach code '(-1 5 330)
(setq flt (vl-remove (assoc code flt) flt))
)
(setq oth (ssget "x" flt)) ; ssget all identical-to-a
(ssdel (ssname oth 0) oth) ; remove one entity

If the entities are truly identical then it doesn't matter which one you
keep, right?

James

"RaghuMN" <nospam@address.withheld> wrote in message
news:17652736.1104722793975.JavaMail.jive@jiveforum1.autodesk.com...

RaghuMN · Guest

Thanks for the idea James.
I had never thought in the way you showed me to tackle this situation.
A good learning experience.

Thanks,

MNRaghu

Joe Burke · Guest

Hi James,

Using 2004 on a Dell 3GHz machine. I think both functions do the same thing.

Just for fun... Though the bounding box method involves more code, I always get
Timer: 0.00000000 seconds, regardless of number of objects in the drawing. My test
file has about 10k objects in model space.

With the filter method, elapsed time seems to depends on the number of objects in the
drawing. With as few as 2k objects, timer returns something on the order of 0.015
seconds. With 10k objects, 0.078 seconds.

In both cases the functions are deleting 7 of 8 duplicate text objects.

Granted, the difference between too fast to measure and 0.08 is meaningless within
context. But it might not be so if a calling function was using one of these as a
sub-function to do what Overkill does.

BTW, you might suspect the (command ".erase" ss "") thing in the filter function
slows it down. Not so in my testing. Commented out returns essentially the same speed
result.

And the bounding box function counts deleted items within the timer, unlike the
filter function.

Regards
Joe Burke

;; delete duplicate objects within bounding box
(defun c:BBDeleteDup ( / ename obj ss minpt maxpt minpt* maxpt* idx cnt)
(setq ename (car (entsel "\nSelect object: ")))
(starttimer)
(setq obj (vlax-ename->vla-object ename))
(vla-getboundingbox obj 'minpt 'maxpt)
(setq minpt (vlax-safearray->list minpt))
(setq maxpt (vlax-safearray->list maxpt))
(setq ss (ssget "W" minpt maxpt))
(ssdel ename ss)
(setq idx 0)
(setq cnt 0)
(repeat (sslength ss)
(setq obj (vlax-ename->vla-object (ssname ss idx)))
(vla-getboundingbox obj 'minpt* 'maxpt*)
(setq minpt* (vlax-safearray->list minpt*))
(setq maxpt* (vlax-safearray->list maxpt*))
(if (and (equal minpt minpt*) (equal maxpt maxpt*))
(progn
(vla-delete obj)
(setq cnt (1+ cnt))
)
)
(setq idx (1+ idx))
)
(endtimer)
(princ (strcat "\nNumber of objects deleted: " (itoa cnt)))
(princ)
)

;; delete duplicate objects with filtered selection
(defun c:FilterDeleteDup ( / ent flt ss)
(setq ent (car (entsel)))
(starttimer)
(setq flt (entget ent))
(foreach code '(-1 5 330)
(setq flt (vl-remove (assoc code flt) flt))
)
(setq ss (ssget "x" flt))
(ssdel ent ss)
(command ".erase" ss "")
(endtimer)
(princ (strcat "\nNumber of objects deleted: " (itoa (sslength ss))))
(princ)
)

;---------------------------------------------------------
(defun StartTimer ()
(setq *start* (getvar "date")))
(defun EndTimer (/ end)
(setq end (* 86400 (- (getvar "date") *start*)))
(princ (strcat "\nTimer: " (rtos end 2 8) " seconds\n")))
;---------------------------------------------------------

James Allen · Guest

You're welcome. Check out Joe's version too.

James

"RaghuMN" <nospam@address.withheld> wrote in message
news:31929055.1104810392732.JavaMail.jive@jiveforum1.autodesk.com...

James Allen · Guest

Hi Joe,

Interesting, I never thought about just comparing bounding boxes. But it
looks like the speed difference has more to do with "x" vs. "w" than
filtering. Consider the following code, which in my test was also too fast
to measure.

;; delete duplicate objects with filtered selection
(defun c:FilterDeleteDup2 ( / cnt enm flt minpt maxpt obj ss)
(setq enm (car (entsel)))
(starttimer)
(setq obj (vlax-ename->vla-object enm))
(vla-getboundingbox obj 'minpt 'maxpt)
(setq minpt (vlax-safearray->list minpt))
(setq maxpt (vlax-safearray->list maxpt))
(setq flt (entget enm))
(foreach code '(-1 5 330)
(setq flt (vl-remove (assoc code flt) flt))
)
(setq ss (ssget "w" minpt maxpt flt))
(ssdel enm ss)
(command ".erase" ss "")
(setq cnt (sslength ss))
(endtimer)
(princ (strcat "\nNumber of objects deleted: " (itoa cnt)))
(princ)
)

In reality, I think the bounding box method would still need filtering as
well. I'd be worried about catching non-like entities with identical
bounding boxes; even totally different geometry, like a circle in a square
for example. And of course there's the possibility of identical geometry
with different properties. But I think by virtue of the windowed selection,
yours would still blaze through with some post-filtering added to it.

Personally, I wouldn't use mine as-is either though because mine, while
short, makes no allowance for roundoff error. In fact in my own test, mine
did not erase one piece of text that by all rights was identical. I would
do more work on the filter (making use of the -4 relational tests to filter
reals) whether using "x" or "w". It sure would be nice if they offered a
built in "equal" operator with a fuz factor in the -4 relational tests...
Oh well.

The mention of a sub-function brings up another point. Windowed selection
is of course view dependent. So is it faster overall to ssget "x", or zoom
around selecting windows? I wonder if carefully crafted filters (allowing
for tolerances) with ssget "x" wouldn't end up being faster in the end (I've
noticed overkill does not zoom around). But then if you also want to handle
merging/welding of overlapping geometry I think the filters would get yet
more complex. And so on...

Did you have good holidays?

James

"Joe Burke" <joburke@hawaii.rr.com> wrote in message
news:41da7fef$1_3@newsprd01...

James Allen · Guest

Joe Burke _originally_ wrote: "Just for fun... " ;) Don't worry, that's
how I took it. But it did get me thinking.

Believe it or not, I don't think it had even occured to me to use the
bounding box to generate a selection window. I think my existing routine
uses a somewhat arbitrary crossing window (yeah, it's the zoom around kind).
But for merging/welding, the crossing window may still be needed for this
approach. For non-crossing windows, I agree about making the window a bit
larger, especially with the potential loss of precision through graphic
selection.

I appreciate the thoughts.

James

"Joe Burke" <joburke@hawaii.rr.com> wrote in message
news:41dbafc7$1_2@newsprd01...

Joe Burke · Guest

Hi James,

Rereading my post, apparently I got lost in my own thought stream. :-)

The reason I played with it in the first place was to see what difference speedwise
there might be between ssget "x" and "w". You know, why search the entire drawing, if
there's a *reliable* way to limit the selection/search area. I emphasize reliable
because I'm not sure a bounding box, without some tinkering, would be so. Tinkering:
scale a point list representing all four points about its center to make it a bit
larger. Then use "wp" rather than "w".

The other idea, comparing bounding boxes, was simply to offer an alternative. It
would work OK if you know the duplicates in question are exact copies on the same
layer etc. Then again, as you said, a filtered selection in a limited area is equally
as fast. So why bother with something which doesn't offer the flexibility of your
method.

I hadn't thought about the fact window selection is view dependent. Good point.

As usual I figure we're just kicking it around. My last post reads like I'm
suggesting this way is better than that. In fact, that was not my intention at all.
Sorry if I gave the wrong impression.

Regards
Joe

	CADForums.net Forum Index -> Customization	All times are GMT Goto page 1, 2 Next
Page 1 of 2