Getting info on hatch entities <part duex>

I had a post in here on 02/24/2005 as follows:

I have a hatch pattern where the lines are set up in a 12"x12" grid. I want
to place a block in the center of one of the "holes". how would I go about
getting the info from the individual lines so that I could find the
intersections? I have a neat little routine that I got from this newsgroup
which will let me get the midpoint between two points.


Here's a crude idea of what I'm trying to accomplish:

I want to insert the block at the midpoint of p1 and p2.
The vertical and horizontal lines represent lines that are within the hatch
pattern.


| p1 |<-----line that is part of the hatch
pattern
----X---------------------
| |
| |
| X<-- insert point of block
| |
| |
----------------------X-----
| | p2

Here's my routine for getting the midpoint:

(defun MidPnt (p1 p2)
(mapcar '(lambda (a b) (/ (+ a b) 2.0)) p1 p2)
)

-----------------------------------------------------------------------------------

I found out that this wasn't exactly possible because you can't actually
pick the individual lines in a hatch. So I went back to the drawing board
<so to speak> and couldn't solve my problem. Does anybody else know of a
way to solve this? I'm just wanting to insert a block in the dead center of
the empty area in the hatch. I've tried to use this to find a distance from
my pick point to it finds an entity, then using some math to find the
center:

(while (= SearchResult nil) ;If nothing is found, keep going
(setq Dist (+ Dist 0.0125)) ;Keep adding the incriments until
something is found
(setq pnt (polar BasePnt CheckAngle Dist)) ;Check angle can vary
(setq SearchResult (nentselp pnt))
(if (/= SearchResult nil)
(if (/= (cdr (assoc 8 (entget (car SearchResult)))) Layer)
(setq SearchResult nil))) ;make sure it's on the proper layer
) ; end while

Problem with this is getting accuracy. If I set the step distance to more
than 0.0125, then it takes way to long to do a search.

Another problem I have is that the areas that are hatched are coming from
different sources. Once place may do the hatching with lines, another with
actual hatches, another with polylines and still yet another using AEC
entities.


Thanks for any help from those who can help.

 

So what your saying is that the user would have to select the two opposite
points? I was hoping to be able to just select a point inside the opening
and then use programming to find the center. Is that even possible?

 

have not done it Jamie...

The possibility I think is to explode the hatch and use bpoly to make a
temporary polyline, grab the bounding box values, get the midpoint or the
center of gravity for the square...

 

At first look, I said "OUCH! Exploding hatches!" But then the thought
occurred that you may be on to something, be it over my head, but on to
something. What if I set up the routine to do as you said. But by somehow
saving the exploded lines identities so that they can be erased later.
Then, would there be a way to save the information about the original hatch
into a variable and so that it can be re-placed as though it was never
exploded? Just thinking off the hip here. I dunno if that is at all
feasible.

 

Jamie,

The problem I see here is that we need to have the entities from the hatch
to play with them, I know how to find an enclosed area mathematically, but I
need to know the elements that form the enclosed area.... even if you use
bpoly is no way....

The easy way is to simple use two point selections.... the intersections...
instead of going the long way....

LE.

 

The easy way is to simple use two point selections.... the

I guess your right. I'm one of those types of people wher if it takes 3
clicks to do something, I want to do it in 2. If it takes 2, I want to do
it in 1. If it takes 1, then I want it to be done automatically. <g> I
guess reinventing the wheel will have to wait until another day. Thanks for
your thoughts Luis. As always, you are one of the people who would know how
to accomplish this if there was a way. You da' man.

 

You could make a copy of the hatch pattern in place, and explode that. The
trick would be to save the resulting lines as a selection set -- I think
there might be a way to do that, but it's not coming to me right now. Then
the lines would be there to do what you want with, and when you erase them
later, the original hatch pattern would still be there.

 

Hey, that's a good idea also, but how would you gather and store the
resulting lines? And, how much trouble would that be on the computer for
having to do it dozens of times <each time the block is inserted> to the
same hatch? Would the regen times be long?

 

WAIT!!
I just thought of something else wrong with doing this. What if the hatch
is part of a xref? Wouldn't be very simple to explode it then. I think the
only solution is the two points pick and find the midpoint.

 

And still another problem. When taking a look at using the intersections of
the hatch lines, to find the two points to extrapolate the midpoint from, I
came across a big problem. I tried to draw a line using the intersection of
lines on a AEC_CEILING_GRID entity, which is within a xref. I wasn't able
to snap on to the intersection. It wouldn't let me snap on to the apparent
intersection. This one has me puzzled for sure. <scratchinghead.mpg>

 

I'm going to put part of the offending file in the customer files ng for you
to check out what exactly it does. More about it in the post over there.

 

Jamie,

I stop doing applications, I am just getting some fun, answering some minor
things over here....

LE.

 

Maybe someone else will be able to figure it out. Thanks anyways.

 

okay....

Just think of something... it is possible to get four points from a vector
selection starting from an internal point,maybe using a ssnamex not sure for
nested objects, and average those points to get the geometric center.

LE.

 

Apparently it didn't make it. I posted it right before I left the office.
I'll have to check it in the morning.

 

That was the direct I was heading until I ran into problems getting the
individual lines from the hatch. When I started, I thought hatches were in
a sense just unnamed blocks. I guess they're not. I'll everually figure
out something. I hope. <g>

 

Well I have to make an exception... actually was very easy... I just finished the routine for you... you want it compiled no?



I'll send you the file tomorrow.

 

Jamie:

You can explode the hatch, calculate your point, then UNDO the explode
before continuing.

 

What if the hatch is part of an xref?

--
Rabbit