Mline swap LSP routine
MATCHPROP only change the color. It does not change the properties to match. I will try to use the command and show you. Once the command is prompted, I select the "0200 AQUA" and then I select the "0036 50% UREA" and all it does is change the backround color of the Mline.
Before MATCHPROP:
After MATCHPROP:
[It doesn't just change the color, but also the Layer.] I didn't realize that MultiLines are some kind of orphan object type -- MATCHPROP won't match their Mline Style. And even though the Style is an entry in their entity data [DXF code 2], I've tried various ways of substituting that from one into the other, so far without success. I also tried to assign the StyleName VLA property, with the same non-result. Maybe I just haven't found the right way yet....
But there may not be one -- I also notice that in the Properties palette, the Style is listed, but greyed out, so it can't even be assigned there. It may be that you're stuck with drawing a new one over the one you want changed.
@joe_kohli wrote:
.... Is there an eaiser way (possibly bypassing Mline) to create these banners? ....
What are they used for?
Do you ever really want them long enough to contain multiple repeats of the text-content part? If you only use them in short-enough pieces to have that once, stuck onto some kind of path object [at intervals, perhaps?], would a Block do it?
They are used to show what product is going through a line via P&ID dwg. So typically you would draw a line or polyline to indicate your process line/piping. Then, you would use those Mlines to snap to the bottom of that process line to show what system it is. Yes, they need to continue to repeat the text-content.
See the example below. The top line is just an indication that it is a "process" line. The bottom still shows that it is a "process" line but also has the system/material snapping to the process line to show you what is in that particular line. So I have "0022 PRS AIR" flowing to a gate valve and after the gate valve the system switches to "0008 50# STM". Hope this makes sense.
@joe_kohli Is there a reason that you don't use polylines with a linetype for the text? In my experience, mlines are not the easiest to work with.
*0036 50% UREA,0036 50% UREA» ----------0036 50% UREA----------0036 50% UREA----------0036 50% UREA----------
A,0.5,-0.812909,["0036 50% UREA",Arial,S=0.15,U=0,X=-0.796606,Y=-0.0735164],-0.812909
@Kent1Cooper wrote:
.... It may be that you're stuck with drawing a new one over the one you want changed.
Experimenting with that as an automated approach, I arrived at this:
(defun C:MLMP ; = MultiLine Match Properties
(/ ML1 ML1data ML2 ML2data)
(setq
ML1 (car (entsel "\nSource MLine: "))
ML1data (entget ML1)
ML2 (car (entsel "\nTarget MLine to match Source: "))
ML2data (entget ML2)
); setq
(setvar 'ltscale (cdr (assoc 48 ML1data)))
(command
"_.layer" "_set" (cdr (assoc 8 ML1data)) "" ; set properties to match ML1
"_.mline"
"_justification" (nth (cdr (assoc 70 ML1data)) '("Top" "Zero" "Bottom"))
"_scale" (cdr (assoc 40 ML1data))
"_style" (cdr (assoc 2 ML1data))
); leave in MLINE command:
(foreach pt ; points in ML2
(mapcar 'cdr (vl-remove-if-not '(lambda (x) (= (car x) 11)) ML2data))
(command pt)
); foreach
(command ""); conclude MLINE
(entdel ML2)
(prin1)
)It works in your sample drawing, and also with MLines of more than one segment, but there are oddities:
Its results sometimes [not always, for some reason] end up with larger text size. Properties shows both the linetype scale and the Mline scale as the same, but the text size is bigger. I don't have any idea what could cause that, nor therefore how to prevent it.
And I tried a couple of ways of getting it to work if the target Mline is closed, both feeding in the "_close" option and imposing the entity-data entry that contains the code for that, without success.
I think Mlines are peculiar in more ways than simply not being able to change their Style after the fact....
@Kent1Cooper wrote:
@ronjonp wrote:.... you could use my MAKELT routine to easily create your linetype definitions.
Or, without the need for any custom routine, just use AutoCAD's built-in MKLTYPE command, which very quickly and easily made this one:
@Kent1Cooper Yes there is the "built-in" LMFTFY "folded in" express tools version. Not a fair comparison IMO. As far as I've seen, the base code for express tools is stuck in the 1990's to early 2000's and not being improved.
Here's showing how outdated the code is.
Command: MKLTYPE
(*pop-error-mode*) underflow.
Cannot invoke (command) from *error* without prior call to (*push-error-using-command*).
Converting (command) calls to (command-s) is recommended.A much simpler way to create and or update linetypes. *clink*
@ronjonp wrote:....
Here's showing how outdated the code is.
Command: MKLTYPE (*pop-error-mode*) underflow. Cannot invoke (command) from *error* without prior call to (*push-error-using-command*). Converting (command) calls to (command-s) is recommended....
The better relationship of the text part to curves is nice [and I've often done that kind of thing with linetype definitions that I spell out], if the OP would ever use such a thing on curves -- do P&ID drawings ever do that?
But just so you know: I do not get that underflow message or the rest when I use MKLTYPE. It works perfectly normally for me, at both Acad2020 and Acad2024 installations. Something must be wrong with your installation.
