How to VLA-ADDMTEXT to specified Layout tab?

[mid-awe]

Hi all,

I've been looking for this answer for a very long time. Switching between layouts programatically is a slow process for many pages and I have for along time now thought about "What if I could do things to a page without actually having to make it current first". How can I add an MTEXT entity to a page without the need for the page to be current first. Can't I simply use the page's name in a function to add the entity to that specific page? As many times as I've come to this conclusion it would seem that others have also.

One such program I worked with a long time ago had to adjust block attributes on seveeral pages but with a hundred or so attributes on more that 10 pages had taken about 10 minutes to complete. Now, in favor of MTEXT with fields for speed and acuracy I find a simular conundrum. Although much faster, I still have the need to add and edit those MTEXT entities on multiple pages and prefer to takle this issue now before the improved functionality rolls out.

Thank you for any suggestion.

[Lee_Mac]

Could you post the section of code that includes the method of storing the handles?

[mid-awe]

Thank you Lee,

This is the entire function. (Everything is working other than the handles for removing the previous MTEXT objects). It's tolerable for testing; I just manually delete the old MTEXT objects each time before running the function.

(DEFUN MKTB (/ OBJ)
  (VLAX-FOR LAY	(VLA-GET-LAYOUTS (VLA-GET-ACTIVEDOCUMENT (VLAX-GET-ACAD-OBJECT)))
    (IF	(WCMATCH (STRCASE (VLA-GET-NAME LAY)) "POOL [BCD] 8")
      (PROGN
	(SETQ OBJ (VLA-ADDMTEXT
		    (VLA-GET-BLOCK LAY)
		    (VLAX-3D-POINT 0.28125 2.4375 0)
		    0.0
		    *TBSTR*
		  )
	)
	(VLA-PUT-WIDTH OBJ 5)
	(VLA-PUT-HEIGHT OBJ 0.08)
	(VLA-PUT-STYLENAME OBJ "ROMAND")
	(VLA-PUT-ATTACHMENTPOINT OBJ ACATTACHMENTPOINTBOTTOMLEFT)
	(VLA-PUT-INSERTIONPOINT OBJ (VLAX-3D-POINT 0.28125 2.4375 0))
	(VLA-PUT-LINEWEIGHT OBJ 0.13)
	(VLAX-LDATA-PUT "TB" (VLA-GET-NAME LAY) (CDR (ASSOC 5 (ENTGET (ENTLAST)))))
      )
    )
  )
  (SETQ *TBSTR* NIL)
  (PRINC)
)

 All suggestions are appreciated.

[Lee_Mac · Accepted solution]

Hi mid-awe,

Personally, I would not recommend using LData to store data in a drawing, as, in my experience, several programmers far more knowledgeable than myself have recommended against its use stating that it has the potential to corrupt drawings under certain circumstances. I would instead recommend using a custom drawing dictionary attached to the named object dictionary.

With regards to your posted function, consider the following two functions:

Visual LISP:

(defun mktb ( str / ins obj )
    (setq ins (vlax-3D-point 0.28125 2.4375))
    (vlax-for lay (vla-get-layouts (vla-get-activedocument (vlax-get-acad-object)))
        (if (wcmatch (strcase (vla-get-name lay)) "POOL [BCD] 8")
            (progn
                (setq obj (vla-addmtext (vla-get-block lay) ins 5.0 str))
                (vla-put-height obj 0.08)
                (vla-put-stylename obj "ROMAND")
                (vla-put-attachmentpoint obj acattachmentpointbottomleft)
                (vla-put-insertionpoint obj ins)
                (vla-put-lineweight obj aclnwt013)
                (vlax-ldata-put "TB" (vla-get-name lay) (vla-get-handle obj))
            )
        )
    )
    (princ)
)

Vanilla LISP:

(defun mktb ( str )
    (foreach lay (layoutlist)
        (if (wcmatch (strcase lay) "POOL [BCD] 8")
            (vlax-ldata-put "TB" lay
                (cdr
                    (assoc 5
                        (entget
                            (entmakex
                                (list
                                   '(000 . "MTEXT")
                                   '(100 . "AcDbEntity")
                                   '(100 . "AcDbMText")
                                   '(007 . "ROMAND")
                                   '(040 . 0.08)
                                   '(370 . 13)
                                   '(071 . 7)
                                    (list 010 0.28125 2.4375 0.0)
                                    (cons 001 str)
                                    (cons 410 lay)
                                )
                            )
                        )
                    )
                )
            )
        )
    )
    (princ)
)

Note that I have set the text content as an argument for the function, rather than relying on the existence & validity of a global variable.

Lee

[mid-awe]

Thank you Lee, you are a lifesaver! 🙂
That works fantastically. I see the "entmakex" right tool for the job.

I believe in the case of the GLOBAL I could just as easily send it as an argument since I make the global in the function that run just before this function runs and I set it to nil asap. It only exists for a second or two and then it's gone. I assumed that it was the best way to compile my string data. I appreciate the advice about LDATA. I know that kind of experience should not be ignored.

Thank you again. ( I'm amazed at how many variations I tried and the solution was right there the whole time 🙂 )

[Lee_Mac]

---

@mid-awe wrote:
Thank you Lee, you are a lifesaver! 🙂

---

You're welcome as always mid-awe!

---

@mid-awe wrote:
That works fantastically. I see the "entmakex" right tool for the job.

---

Indeed, the primary benefit of using entmakex in this situation is the ability to apply multiple proprerties to the MText object simultaneously during entity creation, rather than modifying such properties subsequently using the individual ActiveX property functions.

---

@mid-awe wrote:
I believe in the case of the GLOBAL I could just as easily send it as an argument since I make the global in the function that run just before this function runs and I set it to nil asap. It only exists for a second or two and then it's gone. I assumed that it was the best way to compile my string data.

---

From your description, It sounds as though using an argument for the MText content would be ideal, since the scope of the argument symbol is limited to the function to which it applies.

---

@mid-awe wrote:
I appreciate the advice about LDATA. I know that kind of experience should not be ignored.

Thank you again. ( I'm amazed at how many variations I tried and the solution was right there the whole time 🙂 )

---

Sometimes it just requires another set of eyes to look at the problem