Programming Challenge 24-2
Drawn directions of either do not need to matter, and no calculation of intersecting points is needed, and I was not surprised by anything. Copy the victim in place, and Trim the original on one side of the cutting one, and the copy on the other side. On the assumption that there won't be other closed Polylines in the vicinity than the one you want split, this works in your drawing:
(defun C:SplitPL-KC
(/ cutss cutpl splitss splitpl1 splitpl2 cutmid cutlen outboard1 outboard2)
(prompt "\nFor cutting open Polyline {singular},")
(if
(and
(setq cutss (ssget "_:S+." '((0 . "LWPOLYLINE") (-4 . "<NOT") (-4 . "&") (70 . 1) (-4 . "NOT>"))))
;; single, open only
(setq
cutpl (ssname cutss 0)
splitss
(ssget "_F"
(mapcar 'cdr (vl-remove-if-not '(lambda (x) (= (car x) 10)) (entget cutpl)))
'((0 . "LWPOLYLINE") (-4 . "&") (70 . 1)); closed only
); ssget & splitss
); setq
(= (sslength splitss) 1); only one to be split
); and
(progn ; then
(setq splitpl1 (ssname splitss 0))
(command "_.copy" splitpl1 "" '(0 0) '(0 0))
(setq
splitpl2 (entlast)
cutmid ; midway between ends of cutting one
(mapcar '/
(mapcar '+
(setq cutstart (vlax-curve-getStartPoint cutpl))
(setq cutend (vlax-curve-getEndPoint cutpl))
); +
'(2 2 2)
); /
cutdir (angle cutstart cutend)
cutlen (vlax-curve-getDistAtPoint cutpl (vlax-curve-getEndPoint cutpl))
outboard1 (polar cutmid (+ cutdir (/ pi 2)) cutlen)
outboard2 (polar cutmid (- cutdir (/ pi 2)) cutlen)
); setq
(command "_.trim" cutpl ""
(list splitpl1 (vlax-curve-getClosestPointTo splitpl1 outboard1))
(list splitpl2 (vlax-curve-getClosestPointTo splitpl2 outboard2))
""
); command
); progn
); if
(prin1)
)
Add a restriction to an unlocked Layer for the one to split if you want, and *error* handling and command-echo suppression and Undo begin-end wrapping and so on....
I imagine there could be more convoluted configurations in which it might not give the result you want, but it works in simple situations such as in your drawing. With minor adjustment, the same approach could work with other kinds of cutting edges [Line, "heavy" Polyline, Xline, Ray, etc.*] and other kinds of objects to be split ["heavy" Polyline, Circle, Ellipse, Spline, Mline, Xline, Ray, etc.]. *There would need to approximations made for the Fence selection if the cutting edge were to contain curvature(s), such as a Polyline with arc segment(s), or an Arc, Spline, or partial Ellipse.
@john.uhden wrote:
.... I was expecting that most challengers would get hung up on the BREAK command for a while. How did you know to vla-copy and trim? ....
I knew from past experience that Breaking a closed Polyline at a single point results in 2 Polylines, not just the 1 you might expect with its start/end at that Break point. The original start/end point is the other division between the 2 results. The TRIM approach gets around that, leaving each side as a single Polyline, regardless of where the original start/end was.
[And I didn't vla-copy it. The only (vla...) functions involved are (vlax-curve...) functions, which will happily work with just the entity name, so there's no need to involve VLA object conversion.]
@john.uhden wrote:
... if you supply the target as '(ename . pt) that it will trim only the ename provided, not some other proximitous entity. .... it's (list ename pt) ....
Exactly. Supplying that list [the same as what (entsel) returns], instead of just a point, ensures the right thing gets Trimmed if there could be more than one thing at that point [which there will be in this case]. And as a "plain" list, not a dotted-pair list.
I know it's a hard-enough programming challenge without this extra nonsense.
But I'm reading these codes and thinking to myself "But what about this shape?!" 😅
@CodeDing wrote:
.... "But what about this shape?!"
[Mine handles that situation just fine in certain specific relationships, but fails in others, depending on exactly how they are positioned in relation to each other. It's all in the Fence selection through vertices -- if the cutting one's horizontals are above the level of the one to split, the selection misses the latter. See the last sentence in Message 2.]
@komondormrex wrote:
.... should the split pline's parts be closed with added part of splitter?
For that: It shouldn't be too difficult to cause BPOLY or BOUNDARY in each half, and delete the original closed Polyline.
Because every vertex of a Polyline has a unit parameter value, the difference in the length represented by a particular difference in parameter value can vary greatly, if segment lengths vary a lot. That's why I don't think a parameter-based location of pick points for Trimming is right. If it's to be done by calculating something along the Polyline relative to an intersection point with the cutter, it should be based on distances, not parameters. Here's a rather extreme example, with everything on one side of the [white] cutting Polyline being within the same segment on the Polyline to be split [red], so that in the SPLITP command, the pick points in Trimming, at halfway in parameter value difference from the start point in both directions from an intersection, both fall on the same side of the cutter:
