Broken lines and text to dimension

[Anonymous]

Hi,

I'm new to LISP programming and I'm looking for a lisp routine which converts broken line and text(Broken dimension in DXF format) into proper dimension with required layer. 

Kindly help.

Thanks a million in advance

Regards

Dinesh M

[Kent1Cooper]

---

@Anonymous wrote:

.... I'm looking for a lisp routine which converts broken line and text(Broken dimension in DXF format) into proper dimension with required layer. 

....

---

I don't think that's possible.  But I'm sure the same request has been made before -- if there is anything that can be done, you may find it [or more detail about why it can't be done] with a Search.

[CADaSchtroumpf]

Hi,

I don't know if I have understand better the question (I'm French), but you can try this!

(defun c:cut_dim ( / js n ent_dim dxf_ent lremov dxf_cod pt_break p1 p2 p_nw1 p_nw2)
  (princ "\nSelectionner la cotation: ")
  (setq js
    (ssget "_+.:E:S"
      (list
        (cons 0 "DIMENSION")
        (cons 67 (if (eq (getvar "CVPORT") 2) 0 1))
        (cons 410 (if (eq (getvar "CVPORT") 2) "Model" (getvar "CTAB")))
      )
    )
  )
  (cond
    (js
      (setq
        ent_dim (ssname js 0)
        dxf_ent (entget ent_dim)
        lremov nil
        dxf_cod dxf_ent
      )
      (cond
        ((or (zerop (rem (cdr (assoc 70 dxf_ent)) 32)) (eq (rem (cdr (assoc 70 dxf_ent)) 32) 1))
          (foreach n dxf_cod (if (member (car n) '(2 5 330 -1)) (setq lremov (cons (car n) lremov))))
          (foreach m lremov
            (setq dxf_cod (vl-remove (assoc m dxf_cod) dxf_cod))
          )
          (entmake dxf_cod)
          (setq dxf_cod (entget (entlast)))
          (initget 1)
          (setq
            pt_break (trans (getpoint "\nDonnez le point de coupure: ") 1 0)
            p1 (cdr (assoc 13 dxf_ent))
            p2 (cdr (assoc 14 dxf_ent))
            p_nw2 (polar p2 (angle p2 pt_break) (distance p2 pt_break))
            dxf_ent (subst (cons 14 p_nw2) (assoc 14 dxf_ent) dxf_ent)
          )
          (entmod dxf_ent)
          (setq
            p_nw1 (polar p1 (angle p1 pt_break) (distance p1 pt_break))
            dxf_cod (subst (cons 13 p_nw1) (assoc 13 dxf_cod) dxf_cod)
          )
          (entmod dxf_cod)
        )
        (T
          (princ "\nN'est pas une côte alignée, pivotée, horizontale ou verticale.")
        )
      )
    )
  )
  (prin1)
)

[Anonymous]

Hi,

Sorry I think you understood the question wrongly. What the lisp you provided it is cutting a single dimension into two parts, but what I want is oppsite of that.

Thanks and regards

Dinesh M

[Anonymous]

Can you post a DWG for this? so we know the format of the exploded dimension. 

Thanks

[Kent1Cooper]

---

@Anonymous wrote:

Can you post a DWG for this? so we know the format of the exploded dimension. 

....

---

That hardly seems necessary.  Explode one and you'll know -- some Lines [and/or Arcs from angular Dimensions], an Mtext entity from the text content, Blocks from the arrowheads [or Solids from the default closed-filled type].  I also find that the definition points on the DEFPOINTS Layer don't become Point entities when I Explode a Dimension, but simply disappear, which would make it all the more impossible for a routine to be able to accurately reconstruct the Dimension from which those other parts may have come [but one thing I don't know is whether those survive the transition through DXF format if the Dimensions were "whole" in the source drawing].

Even if one could imagine selecting exactly the right set of parts to put back together into one Dimension entity, and a routine being able to evaluate things about them [such as determining which two Lines are parallel (and also "aim" at the definition Points if those are present) that were the extension lines, or whether two Arcs are concentric and two Lines are radial from their common center, and whether two Blocks or Solids relate appropriately to the presumed extension lines, and so on], there are so many potential complications:

:: All sorts of parts of Dimensions can be suppressed, so there might not be two extension lines, or two arrowheads, or ...;

:: Arrows and/or text can be inside or outside extension lines or some of each, and text could be out-of-line anywhere at the end of a leader-connector;

:: If it can determine the distance between two parallel Lines and assume they were the extension lines, but the Mtext content doesn't match the distance between them, the difference might be a result of the rounding-off value or that the text content was explicitly overridden;

:: If the text contains more than just linear/angular values, there would be no way to determine whether that was an override or a prefix or suffix built into the Dimension Style definition;

:: There would be no way to determine from the pieces the difference between a Dimension that was drawn with the more generic DIMLINEAR from one that was drawn with the more specific DIMHORIZONTAL or DIMVERTICAL, or with DIMROTATED, or with DIMALIGNED even if the extension lines are the same length and not orthogonal [e.g. it could have been DIMLINEAR under a different UCS], but the difference could be important [i.e. it would affect how it would be changed if you later Stretched something];

:: If the definition points are not there, there would be no way to determine where they would have been in relation to the ends of extension lines, because that would have been determined by the extension-line offset variable value for the Dimension Style it was drawn with, but the pieces won't carry any information about that;

:: There could be different numbers of dimension lines/arcs depending on the text-location settings of the Style;

:: I'm sure I could come up with some more if I thought about it further....

It seems to me that in order to reliably "get it right," a routine to do this would need to ask the User for enough specifics in selections, and with enough qualifications, that it would not be any less work than just Erasing those pieces and drawing the Dimension anew.