Topic: question about offset,hope someone can help me!

[Tsec2nd]

Please see the attached file. The draft 1 is the original ,when use the offset command(offset distance is big than the half of the narrowest gap),the result is draft 2,but what I want is the result like draft 3.Can anyone help me? Thanks!

[ribarm]

It is known bug of LWPOLYLINE entity... You have to recreate it and then apply OFFSET command on new LWPOLY... So firstly apply this code on reference LWPOLYLINE and then try OFFSET... Tell us is it working... Thanks...

Code: [Select]

(defun c:recreatelw ( / lw pea )
  (while
    (or
      (not (setq lw (car (entsel "\nPick closed LWPOLYLINE..."))))
      (if lw
        (or
          (/= (cdr (assoc 0 (entget lw))) "LWPOLYLINE")
          (or
            (= 0 (cdr (assoc 70 (entget lw))))
            (= 128 (cdr (assoc 70 (entget lw))))
          )
        )
      )
    )
    (prompt "\nMissed or picked wrong entity type, or picked LWPOLYLINE is open...")
  )
  (setq pea (getvar 'peditaccept))
  (setvar 'peditaccept 1)
  (vl-cmdf "_.EXPLODE" lw)
  (while (< 0 (getvar 'cmdactive))
    (vl-cmdf "")
  )
  (vl-cmdf "_.PEDIT" "_L" "_J" "_P" "" "")
  (setvar 'peditaccept pea)
  (princ)
)

Regards, M.R.

[Tsec2nd]

Thanks for your reply.I have found the reason. It is caused by "offsetgaptype".

[ribarm]

"offsetgaptype" has noting to do with functionality of OFFSET ecept the way connections are created after offset... Your question was answered correctly as the real issue is LWPOLYLINE bug... Have you even tried my solution?... I know that it is cumbersome especially if LWPOLY had XDATA attached to it, so after recreate you'll loose it, but it should offset correctly just like you showed in your DWG - expexting result part...

[Tsec2nd]

Your cods have solved the problem pefectly! Thank you very much!

[ribarm]

I've checked your example once again... If you have XDATA attached to LWPOLY, try using REVERSE command just once on your polyline... On your example it worked for me... Not sure, but maybe this is better soulution to this bug, still just not sure if it's applicable for all cases where this bug may occur...

[ribarm]

Sorry, bad news... I've recreated bug, but on my example REVERSE didn't work... So recreate LWPOLYLINE is the only correct fix... I am sorry...

[Tsec2nd]

Thank you for your help anyway. 

[ribarm]

I am revising this issue again as I realized that this is not as I thought LWPOLYLINE bug, but normal bahaviour of this entity type... So, I figured out that this issue occur when starting vertex of LWPOLY is positioned such that offseting calculation is not possible... For instance you have rectangle and one smaller rectangle crossing bigger side of bigger rectangle, then when you trim lines to get boundary outline and perform JOIN command, usually starting vertex is common intersection of those 2 rectangles. Now if you try offset you'll see that previewing is possible all until smaller boundary rectangle shape is present. When you move mouse beyond that distance instead of previewing now only bigger boudary rectangle offset shape, small icon (-) will pop up telling that this isn't possible... So I instead of exploding and rejoining lines to new LWPOLY, decided to change initial vertex of LWPOLY... And whoala, that did the trick... It is possible that when explode and rejoining, newely created LWPOLY changed initial vertex automatically - this happens also if you perform one single REVERSE command... But this all is not very reliable - I figured out that you should check every position of starting vertex so that you could be sure if offset is possible or not... This finding tells me that routines may be more slower, but this checking is necessity if you want to be sure that this situation not happen (offset bug)...

So here is routine for checking and you may strip sub function from it :

Code: [Select]

(defun c:CHIV ( / osm ss e f ed edd eddd eddd1 eddd2 eddd3 newed p m n i )

  (vl-load-com)

  (setq osm (getvar 'osmode))
  (setvar 'osmode 1)
  (prompt "\nPick closed 2d polyline with or without arcs")
  (setq ss (ssget "_+.:E:S:L" '((0 . "*POLYLINE") (-4 . "<or") (70 . 1) (70 . 129) (-4 . "or>"))))
  (if ss
    (setq e (ssname ss 0))
    (progn
      (setvar 'osmode osm)
      (alert "Picked wrong entity... Please pick normal closed 2d polyline next time-quitting...")
      (exit)
    )
  )
  (if (eq (cdr (assoc 0 (entget e))) "POLYLINE")
    (progn
      (setq f t)
      (vl-cmdf "_.convertpoly" "_l" e "")
    )
  )
  (setq ed (entget e))
  (setq edd nil)
  (foreach ec ed
    (if (not
          (or (eq (car ec) 10) (eq (car ec) 40) (eq (car ec) 41) (eq (car ec) 42) (eq (car ec) 91) (eq (car ec) 210))
        )
        (setq edd (cons ec edd))
    )
  )
  (setq edd (reverse edd))
  (setq eddd nil)
  (setq eddd1 nil)
  (setq eddd2 nil)
  (setq eddd (member (assoc 10 ed) ed))
  (setq p (getpoint "\nPick vertex you want to become initial"))
  (setq m (vlax-curve-getparamatpoint e (vlax-curve-getclosestpointto e p)))
  (if (assoc 91 ed) (setq n (* m 5)) (setq n (* m 4)))
  (setq i 0)
  (foreach ec eddd
    (progn
      (setq i (+ i 1))
      (if (<= i n)
        (setq eddd1 (cons ec eddd1))
      )
      (if (> i n)
        (setq eddd2 (cons ec eddd2))
      )
    )
  )
  (setq eddd1 (reverse eddd1))
  (setq eddd3 (list (assoc 210 eddd2)))
  (setq eddd2 (cdr eddd2))
  (setq eddd2 (reverse eddd2))
  (setq newed (append edd eddd2 eddd1 eddd3))
  (entmod newed)
  (entupd e)
  (setvar 'osmode osm)
  (if f
    (vl-cmdf "_.convertpoly" "_h" e "")
  )
  (alert "After CHIV, run PEDIT->Edit Vertex to see change")
  (princ)
)

So after all, there is no need for destroying LWPOLY and XDATA issue can be saved by applying this method of checking starting initial vertex along LWPOLY by simply iterating through all positions that are stored in LWPOLY entity data...

HTH., M.R.