Message 1 of 49
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report
Is there a Lisp that can sum two texts and bring the total to the next text?
Solved! Go to Solution.
Is there a Lisp that can sum two texts and bring the total to the next text?
Solved! Go to Solution.
I'm sure that's possible, but explain more....
What are we looking at in the image? The "before" condition? [It can't be "after" since no Text content in the box appears to be the sum of any two others.] What would the "after" condition be? An additional Text object to be added? Or to change the content of one already drawn? [That is, what is meant by "next" text?] What would the User's process be? Asked to select two of them and then where to put a new one that represents their sum? Asked to select two, and then to select one to change to represent their sum? Asked to select two, and the routine would somehow find the "next" one to change the content of? Etc., etc.
That is, I select the first text and then the second text, and put the sum of the two in the second text.
@Oliver_C3D wrote:
That is, I select the first text and then the second text, and put the sum of the two in the second text.
Something like this [minimally tested]:
(defun C:SNT2 ; = Sum of Numerical Texts into 2nd one selected
(/ txt1 txt2 txt2data sum)
(setq
txt1 (car (entsel "\nFirst numerical Text object: "))
txt2 (car (entsel "\nSecond numerical Text object to have content changed to sum with First: "))
txt2data (entget txt2)
sum (+ (atof (cdr (assoc 1 (entget txt1)))) (atof (cdr (assoc 1 txt2data))))
); setq
(entmod (subst (cons 1 (rtos sum 2 2)) (assoc 1 txt2data) txt2data))
(princ)
); defun
It doesn't check that you actually picked things, nor that they're both Text objects, nor that their content represents numbers, but all that can be added. It would also work with Mtext if it has no internal formatting but just plain content representing a number.
Unfortunately, text format does not work for this model!
@Oliver_C3D wrote:
Unfortunately, text format does not work for this model!
No, it wouldn't -- chainage numbers are a very different animal from ordinary numbers.
To do that would require the routine to determine that it's dealing with chainage numbers, find the part of the text content that follows the + sign in each, work with the resulting numbers, check whether the sum needs any leading zero(s), and put the sum back with the + sign and what comes before it.
But what if the first is 0+234.56 and the second is 0+890.12 -- should the end result be 1+124.68? You see the complications....
I've tweaked Kents lisp to work with chainages. This assumes the number before the + is in thousands of units.
(defun rh:ri_str (new old str) (while (vl-string-search old str) (setq str (vl-string-subst new old str))) str)
(defun C:SNT2 ; = Sum of Numerical Texts into 2nd one selected
(/ txt1 txt2 txt2data sum tsum)
(setq
txt1 (car (entsel "\nFirst numerical Text object: "))
txt2 (car (entsel "\nSecond numerical Text object to have content changed to sum with First: "))
txt2data (entget txt2)
sum (+ (atof (rh:ri_str "" "+" (cdr (assoc 1 (entget txt1))))) (atof (rh:ri_str "" "+" (cdr (assoc 1 txt2data)))))
); setq
(setq tsum (strcat (if (< sum 1000) "0" (itoa (fix (/ sum 1000)))) "+" (rtos (rem sum 1000) 2 2)))
(entmod (subst (cons 1 tsum) (assoc 1 txt2data) txt2data))
(princ)
); defun
I am not one of the robots you're looking for
This Lisp is exactly what I wanted. It was great and wonderful.
Thank you very much
This Lisp does not work properly in this section!
For example, adding 1 + 76.84 with 100.45 gives the result: 0 + 277.29 !!!
This Lisp does not work properly in this section!
For example, adding 1 + 76.84 with 100.45 gives the result: 0 + 277.29 !!!
That's clearly because it should be 1 + 076.84.
Yes, that's the problem!
his Lisp does not work properly in this section!
For example, adding 1 + 76.84 with 100.45 gives the result: 0 + 277.29 !!!
@Oliver_C3D wrote:
Yes, that's the problem!
So is the problem that it was incorrectly formatted, or that the procedure needs to be able to work in either kind of format? @dlanorh 's routine figures out the numerical value by simply removing the + sign, so if there may not always be three characters between that and the decimal point, a different approach will be needed.
Yes there should be three characters!
[I don't think there's any need for a sample drawing -- the concept is simple enough.] Is it likely that you will sometimes get similarly incorrectly-formatted text objects? It would certainly be possible to write something could account for varying numbers [up to 3, anyway] of characters between the + sign and the decimal, though not for other kinds of incorrect formats [raw typing errors such as more than 3 characters there, or letters included, or other weirdnesses].
Sample