Topic: (Challenge) find the coordinates of a line...

[BazzaCAD]

The challenge is to find the coordinates of the line in THIS dwg. 

[Kerry]

Seems unusual that it's located by it's center ... ?

[BazzaCAD]

I guess I should of said the start & end point coordinates.

[Josh Nieman]

oh fudge..

I saw the title and thought "oh man, even _I_ can write this one!!"

way to kill my spirits

[Kerry]

I know what you meant
any programmatic solution would need prior knowledge of the item.
... and know that a positive offset is actually negative

[BazzaCAD]

any programmatic solution would need prior knowledge of the item.
... and know that a positive offset is actually negative

Sorry, I'm not sure I know what you mean. What else do you need?

[Kerry]

Nothing.

[BazzaCAD]

oh fudge..

I saw the title and thought "oh man, even _I_ can write this one!!"

way to kill my spirits

Sorry Josh,
Maybe we'll both learning something from this challenge.

[Josh Nieman]

well using 'list' I find that it's inserted at point, X= 124.3487  Y=  25.9280  Z=   0.0000

Luckily the block creator was wise enough to list the "Gap Dist" in the custom properties of that block, (6.000) and the Overall Length, as well, (79.5142) and thus, using geometry, I figure it'd be easy to figure the coords, since the angle of the line is also included in the custom properties... I'm not 100% sure, but I am guessing... that via lisp, you can extract even the 'custom property' values.... but that's a 100% assumption.

unfortunately, though I may be able (if I was lucky) to assert the path to follow to derive the right answer... I lack the programming skills to translate that into the right language.

[Jeff_M]

Quick & dirty and only works in WCS and if the block is uniformly scaled.....
Pass the function a VLA-OBJECT of the dynamic line.

Code: [Select]

(defun dynlineendpoints (line / tmp rslt)
  (setq tmp (car (vlax-invoke line 'explode)))
  (setq rslt (cons (vlax-curve-getstartpoint tmp)
   (list (vlax-curve-getendpoint tmp))
   )
)
  (vla-delete tmp)
  rslt
  )


Command: (dynlineendpoints (vl-sel))

Select object: ((95.5246 8.3578 0.0) (153.173 43.4983 0.0))

[Josh Nieman]

dude, explode a copy... that's cheating!!

(and much more efficient then how I was going to do it... but that's playing dirty)

[BazzaCAD]

Ya that's a great idea.
I wonder how my code will handle getting the coordinates of a bunch of DynBlk's...

[LE]

Hope that helps.

Code: [Select]

(defun dxf (f lst) (cdr (assoc f lst)))

(defun trans-blk-pts  (ptblk ins_pt ang fx fy / sinang cosang xptblk
       yptblk)
  (setq sinang (sin ang)
cosang (cos ang)
xptblk (car ptblk)
yptblk (cadr ptblk))
  (list
    (+ (- (* xptblk cosang fx) (* yptblk sinang fy))
       (car ins_pt))
    (+ (+ (* xptblk sinang fx) (* yptblk cosang fy))
       (cadr ins_pt))
    0))

(defun draw_point  (pt col / d)
  (setq d (* (getvar "viewsize") 0.015))
  (grdraw
    (trans (polar pt (* 0.25 pi) d) 0 1)
    (trans (polar pt (* 1.25 pi) d) 0 1)
    col
    (- col))
  (grdraw
    (trans (polar pt (* 0.75 pi) d) 0 1)
    (trans (polar pt (* 1.75 pi) d) 0 1)
    col
    (- col)))

(defun nestobj (/ ndata edata matrix pin block
data etype p10 p11 z10 z11
zfactor pts return)
  (if (and (setq ndata (nentsel)) (> (length ndata) 2))
    (progn
      (setq edata  (assoc 10 (entget (car ndata)))
    matrix (caddr ndata)
    pin    (last matrix)
    block  (car (last ndata))
    data   (entget block)
    etype  (cdr (assoc 0 (setq elst (entget (car ndata))))))
      (cond
((= etype "LINE")
(setq p10     (cdr (assoc 10 elst))
       p11     (cdr (assoc 11 elst))
       zfactor (cdr (assoc 43 data))
       ins_pt  (cdr (assoc 10 data)))
(if zfactor
   (progn
     (setq z10 (* (caddr p10) zfactor))
     (setq z11 (* (caddr p11) zfactor))))
(foreach block (last ndata)
   (setq data (entget block)
p10  (trans-blk-pts
p10
(dxf 10 data)
(dxf 50 data)
(dxf 41 data)
(dxf 42 data))
p11  (trans-blk-pts
p11
(dxf 10 data)
(dxf 50 data)
(dxf 41 data)
(dxf 42 data))))
(if z10
   (setq p10 (list (car p10) (cadr p10) z10)))
(if z11
   (setq p11 (list (car p11) (cadr p11) z11)))
(grdraw p10 p11 7 -7)
(setq return (list "LINE" (list p10 p11)))))))
  return)

(defun C:GETENDS  (/ data)
  (if (and (setq data (nestobj)) (= (car data) "LINE"))
    (progn
    (draw_point (car (cadr data)) 1)
    (draw_point (cadr (cadr data)) 1))) (princ))

(princ)

If you have already a function to calculate those two points, I would like to see it. Thanks.

[Kerry]

Barry,

(are you in a 'stepping sideways' mood )

What is the bounding-box returned from an interrogation of your object.

... perhaps a redundant thought because of ucs's though .... 

... and also wouldn't identify a start as such ( I assume this is dependant on the rotation direction of the Dynamic Block)

[asides]
Should there be a different offset each end. ?
The result is interesting when the .offset is larger than the .length.
How do you handle an instance where you require the actual end to extend past the 'workPoint' ?

[ElpanovEvgeniy]

My variant... 

Code: [Select]

(defun test (/ mi ma)
 (vla-GetBoundingBox (vlax-ename->vla-object (car (entsel))) 'mi 'ma)
 (list (vlax-safearray->list mi) (vlax-safearray->list ma))
)

[Kerry]

hehehe

Evgeniy,
I've reconsidered my comments   that code works great if the line is oriented lower-left to upper-right, but fails otherwise ..

[ElpanovEvgeniy]

hehehe

Evgeniy,
I've reconsidered my comments   that code works great if the line is oriented lower-left to upper-right, but fails otherwise ..

"The challenge is to find the coordinates of the line in THIS dwg."

In the task points of the beginning and the end were not asked!
It is necessary to search for coordinates, I have found 

[Kerry]

.......  "The challenge is to find the coordinates of the line in THIS dwg."
......
It is necessary to search for coordinates, I have found 

Clever !

[BazzaCAD]

Wow LE (Luis),
That's impressive, I can't be leave that was even passable without 1 VL* function.
No I don't have the answer to the riddle. I actually ask one of the Adsk developers & they said they didn't think it was passable.
Guess you've proven them wrong.

Kerry, why do you aways have to ask the difficult questions?
Yes, I'm thinking about side stepping. The actual DynBlk is much more complicated then the version I posted.
I just made it as simple as passable to try to see if it was even passable since I was told it wasn't.
I'm now thinking the LINE was a bad idea for the block. The real DynBlk has lots of lines in it, so how to determine which line you want the coords of?
I guess I could put that line on a special layer & get the coods of the line that's on that layer.
Opt. 2 would be to use POINT object in the DynBlk, then just get the coods of those 2 points & not even look at the lines...

Here's a screen shot of the actual block I need to work on. It shows the line I need to coods of, or Opt. 2 the points to get the coods of...
Fun ha? & that's only 1 visibility state.....
It's a DynBlk for ShearWalls in a building. We place them all over the place then we extract the coods to a txt file and the Engineers import them into there engineering software to run there calculations and all that stuff with.

Thx for all the help guys. It's really helpful.

[BazzaCAD]

hehehe

Evgeniy,
I've reconsidered my comments   that code works great if the line is oriented lower-left to upper-right, but fails otherwise ..

"The challenge is to find the coordinates of the line in THIS dwg."

In the task points of the beginning and the end were not asked!
It is necessary to search for coordinates, I have found 

LOL, ok you win.

[ElpanovEvgeniy]

I have won! 

[ElpanovEvgeniy]

I give victory LE!
In its program there are more than words...

[BazzaCAD]

I have won! 

I'll ask Kerry to send you some black jelly beans.
But actually if we're choosing a winner I'd say it would have to be LE (Luis) at this point in time.

[Kerry]

Barry, The solution should be possible in code.

The Block has  x, Y, Z scale and rotation.
The Length, left and right are attributes.
Thats all thats needed ... just some vector geometry  simple

... just as Luis demonstrated.

[Kerry]

though this doesn't look correct ..

(GRDRAW p10 p11 7 -7)

I think they'd need to be translated from world to ucs ( which is what grdraw uses)

[BazzaCAD]

Barry, The solution should be possible in code.

The Block has  x, Y, Z scale and rotation.
The Length, left and right are attributes.
Thats all thats needed ... just some vector geometry  simple

... just as Luis demonstrated.

Yes, I see the light, anything is passable...
When I tried to figure this out before I was using the VL object & functions & all I could get was the coods of the block definition, not where the line was stretched to.
But like always Luis is the man.

[BazzaCAD]

My question is, why is the (draw_point) function included?
Yes it's cool, but isn't required to solve the prob. (but still appreciated)

[Kerry]

Barry,
when you get a chance to have a good look at Luis's code the core is this ..

(setq ndata (nentsel))  to select the nested entity (the line)

The rest is assertions and translations due the the particular properties of a block.

I'm intending to  deduct from the beauty of the routine by stating it as simply as that.


added :
and yes, the (draw_point) is for artistic license to visually identify the extents of the line.

good stuff Luis

[BazzaCAD]

Ya I noticed that.
Learn something new every day. I always use (entsel).
Right now I'm converting the code to loop through the block looking for points & getting there coods.
The next hurdle is how to get it to work on a Selection Set. Since I'll have to run this on a whole dwg with lots of DynBlks in it.
I.E. How do you use the (nentsel) with a SS?
Maybe I'll figure out a way of doing this without the (nentsel), since I'm looping through the block anyways...