Combine Multiple Mtext into 1 Mtext
@Anonymous wrote:Works quite well. Would like the option to select text and the program determines if it is mtext or text and finally convert it to one mtext.
I've been finding I could use something just like that recently, and had forgotten about this thread, so I gave it a shot -- try the attached JoinMtext.lsp [command name: JMT]. See commentary at the top of the file.
Kent Cooper, AIA 
@Anonymous wrote:When I run the joinmt.lsp and I first select an mtext entity, I'm getting :-
Error: no function definition: VLAX-ENAME->VLA-OBJECT
Add this line:
(vl-load-com)
near the top of the file -- say, right below the top (defun) line. I often forget to include that, because something in my Architectural Desktop loads it for me, so I never get that error.
Kent Cooper, AIA
@diagodose2009 wrote:
Hello i fixed a few bugs...
....
Please identify what the "bugs" are, and I will consider whether they should be addressed. The "source Lisp" in the image doesn't appear to change anything of substance. But various things about it are bizarre....
It is invalid in many places. It uses underscores in place of hyphens in many (vla...) function names, and weirdly has a 4 in place of -> in conversions [both ways] between enames and vla-objects. Maybe those are separately-defined sub-routines that aren't shown, though I can't conceive of a reason to do that with function names so similar to, and operation apparently identical to, those of the "real" functions, nor if there's some reason to do that, why others were not similarly redefined. Or maybe that's the form they need to be in for C++, but in the Lisp version they won't work that way.
It uses (terpri) at the end in place of Joe Burke's original (princ). That at least prevents the number returned by the final (setvar) from appearing at the Command: line, but it puts nil there. Everyone else uses (princ) or (prin1) or (print) at the ends of routines to not put anything there ["exit quietly" as it says in the Help for (prin1)], and it's beyond my comprehension why one would change that to something that puts nil there instead.
It unnecessarily pulls portions out to define a sub-routine that is used only once -- pointless. At the end of that, it unnecessarily sends out the value of the variable it just set, whereas having that (setq) as the last function in the sub-routine means that what the (setq) returns will be returned by the sub-routine, anyway.
It unnecessarily defines some localized variables as nil at the beginning, which is wasted code because localizing them has already done that for their use within the routine.
Why it does the deleting of subsequently-selected objects as the setting of a variable [which is apparently never used] is completely beyond me.
Kent Cooper, AIA
Accepted solution
So wouldn't you know it -- after building JoinMtext to put a blank line between the contents of selected objects when it combines them, as I thought I would usually want, the first time I actually went to use it in some real work, I found that I wanted all three possibilities [mentioned in the comment at the double Enter] -- one to join everything into one paragraph with only a space added between the selected objects' contents; one to start a new paragraph for each one's content without a blank line between, and one to put a blank line between as the original does. So I adjusted it to make three varieties.
The attached OneMtext.lsp defines three commands: 1MT0, 1MT1 and 1MT2. The 1MT part is about combining Mtext/Text objects into One Mtext object. The number at the end is the number of Enters added between the contents of each selected object [0 adds a Space, 1 starts a new paragraph for each, 2 adds a blank line between]. You could easily make variations with more than 2 Enters if you have a use for such things....
I also chose to force "Exactly" line spacing [my preference] -- you can eliminate that line if you want to retain whatever the line spacing style is of the first-selected Mtext or the default if the first one is converted Text, or you can change the 2 to a 1 to force "At least" spacing.
In addition to accepting both Mtext and Text objects, they have a few other differences from TXT2MTXT:
1. The order of selection determines the order of the joined contents, rather than the relative positions of the pieces. That does mean that you need to pick the pieces one at a time, and not with something like a window.
2. They take the first-selected object [converting it to Mtext if it’s Text], and add each subsequently-selected object’s content to the end, with the added Space/Enter[s], retaining the first-selected object’s text Style, height, rotation, Layer, color, etc., and incorporating within all of that the subsequently-selected objects’ textual content only. [TXT2MTXT retains differences in font, height, color, etc. between selected Text objects.]
3. If the first-selected object is Mtext, they retain its defined width, so content from other objects with different widths can end up with line breaks in different places. If the first-selected object is plain Text, and any of the other objects is Mtext with a non-zero defined width, the width of the widest one of those will be applied to the result, to minimize effects on formatting. If all are plain Text, they use the width of the first-selected one.
Kent Cooper, AIA
@Anonymous wrote:Nice, you must program in your sleep.
What happend to your buddy diagodose2009, he posts his two cents worth of who knows what and then vanishes like the wind? ....
Thank you -- I wouldn't say that, but I can get kind of obsessed sometimes.
[I wonder whether the Moderator has removed diagodose2009's posts. I don't think you can Delete one of your own after anyone has replied to it, as I did to the first one that used to be on this thread (and now my reply is kind of meaningless). A lot of them seem like, or at least seem to contain, commercials, or maybe all the emphasis on C-based programming languages was deemed inapplicable here.]
Kent Cooper, AIA
@autofatalerror wrote:thanks guys
this has helped me
cheers
It's always good to see that people are searching the discussion group, and actually finding things they can use in past threads. Fairly often, without doing that first, someone will ask a question, the answer to which is a link to a thread they could have found themselves if they had looked. So thank you for looking!
Kent Cooper, AIA
@Anonymous wrote:Routine is nice, is there anyway to add a space when joing the differert mtext together to seperate them.
If you really mean just an in-line space, without any Enter/hard-return, that's what 1MT0 does. If you mean a vertical space between lines, that is, a blank line in between the contents of each selected Text/Mtext object, that's what 1MT2 does. Do they not work that way for you? Or are you talking about something else?
Kent Cooper, AIA