I sometimes need to change existing QLEADERS from one style to another wherein the mtext are different sizes in the different styles. Changing the current dimstyle and using dim>>update only affects the leaders, not the text. I have to scale them. I have a routine that scales multiple objects from their insertions, but I'd like to eliminate the step.
I've been coding today and have had a routine working to the point where the leader's mtext sub-entity list is modified, but the entmod call is having no effect. I'm looking at two VLIDE inspection windows for mtext, before and after the run, and they are different, and the after is exactly what I want, but entmod is not working for some reason.
I can't seem to find the page right now but the help said that in addition to certain specific restrictions on the use of entmod (type and handle, internal fields, and viewports), there are "other restrictions" for dimensions, but didn't say what they are. A QLEADER is a dimension...sorta.
Any help?
Have you considered using MLeaders instead?
"How we think determines what we do, and what we do determines what we get."
Went about it a only slightly differently. I sifted through a selection set of leaders and text for mtext objects, got their names and modified their data lists, intead of accessing their names througnh the assoc 340 of their leaders, then called entmod for each, but without effect. The other difference was that instead of a real I was feeding a variable to the cons. The variable was a real based on a calculation derived from the DIMTXT variable and the DIMSCALE. Don't know if this is a problem :
(setq newtextdata (subst (cons 40 <variable>) (assoc 40 textdata)))
(entmod newtextdata)
Inspection window said this worked. The only thing that wouldn't was the entmod. Could it have anything to do with the reactor?
@Anonymous wrote:There's an advantage in this regard?
Inherently, yes... An MLeader style controls both the Leader(s), and the annotation (i.e., text size, text style, etc.).
HTH
"How we think determines what we do, and what we do determines what we get."
@Anonymous wrote:
Went about it a only slightly differently. I sifted through a selection set of leaders and text for mtext objects, got their names and modified their data lists, intead of accessing their names througnh the assoc 340 of their leaders, then called entmod for each, but without effect. The other difference was that instead of a real I was feeding a variable to the cons. The variable was a real based on a calculation derived from the DIMTXT variable and the DIMSCALE. Don't know if this is a problem :
(setq newtextdata (subst (cons 40 <variable>) (assoc 40 textdata)))
(entmod newtextdata)
Inspection window said this worked. The only thing that wouldn't was the entmod. Could it have anything to do with the reactor?
Nash,
both, LEADER and MTEXT, are successfully modified with entmod, just for testing, try
(defun c:test (/ H ITM LEADERDATA NEWLEADERDATA NEWTEXTDATA NUM SS TEXTDATA) (if (setq ss (ssget "_:L" '((0 . "LEADER")))) (progn (setq h (+ (getvar 'DIMTXT)(getvar 'DIMSCALE)));; a variable with the new height (setq itm 0 num (sslength ss)) (while (< itm num) (setq LeaderData (entget (ssname ss itm))) (setq NewLeaderData (subst (cons 72 1) (assoc 72 LeaderData) LeaderData));; change to spline (entmod NewLeaderData) (setq TextData (entget (cdr (assoc 340 LeaderData)))) (setq NewTextData (subst (cons 40 h) (assoc 40 TextData) TextData));; change Text height to variable h (entmod NewTextData) (setq itm (1+ itm)) );; while );; progn );; if (princ) );; test
HTH
Henrique
Thanks for your assistance Henrique. I lost the code I had developed du to a forced restart, but looked at yours and it was basically what I was doing. I redid the coding this morning and the entmod worked. It must have been something stupid like a misspelled variable name but I'll never know. Here's my functional code:
(defun c:dimup ( / tsize tcol mtextss dimss ss counter ent)
(setq tsize (* (getvar "dimtxt")(getvar "dimscale"))
tcol (cdr (assoc 178 (tblsearch "dimstyle" (getvar "dimstyle"))))
mtextss (ssadd)
dimss(ssadd)
)
(prompt "Update dimensions and leaders to curent dimension style")
(setq ss (ssget)
counter (sslength ss)
)
(while (> counter 0)
(setq ent (entget (ssname ss (1- counter))))
(if
(or (eq (cdr (assoc 0 ent)) "LEADER")(eq (cdr (assoc 0 ent)) "DIMENSION"))
(progn
(ssadd (cdr(assoc -1 ent)) dimss)
(if (eq (cdr (assoc 0 ent)) "LEADER")
(ssadd (cdr(assoc 340 ent)) mtextss))
))
(setq counter (1- counter)))
(setq counter (sslength mtextss))
(while (> counter 0)
(setq ent (entget (ssname mtextss (1- counter)))
ent (subst (cons 40 tsize) (assoc 40 ent) ent)
ent (subst (cons 62 tcol) (assoc 62 ent) ent)
)
(entmod ent)
(setq counter (1- counter)))
(command "dim" "up" dimss "" "exit")
(princ)
)
It's curious that the textstyle in a dimstyle does not seem to be controlled by a dim*** system variable. Almost every aspect of a dimstyle is.