Author Topic: Exploding multileaders but preserving the leaders?  (Read 19547 times)

0 Members and 1 Guest are viewing this topic.

yarnstormer

  • Guest
Exploding multileaders but preserving the leaders?
« on: August 22, 2013, 09:16:18 AM »
Ok I know it's a bad bad idea to explode multileaders but I am giving my civil 3d dwgs to a microstation user for conversion and he has asked that I explode them. He has also asked that I pedit the leaders back into polylines - which turn into separate entities when you explode the multileaders. He is ok with the resulting multiline text from exploding the multileaders.

Any ideas? I am not a programmer at all.

I know I can do my own dgn conversion but we are providing these files to the dot and would prefer that they are clean and tested and there are no problems. It's just easier to have this fellow do the conversion.

I just got my boss sold on using multileaders so I need a cool fix for this! I do of course copy my drawing to another name before I do the massive cleanup necessary before I send it out to be converted.

Thanks for any suggestions you might have!

Lee Mac

  • Seagull
  • Posts: 12905
  • London, England
Re: Exploding multileaders but preserving the leaders?
« Reply #1 on: August 22, 2013, 09:18:00 AM »
Are the resulting MLeader components all on the same layer?

If so, isolate the layer, then:

PEDIT > M > Select all Exploded MLeaders > J > Enter > Enter
« Last Edit: August 22, 2013, 09:22:51 AM by Lee Mac »

Matt__W

  • Seagull
  • Posts: 12955
  • I like my water diluted.
Re: Exploding multileaders but preserving the leaders?
« Reply #2 on: August 22, 2013, 09:35:21 AM »
Try exporting to DGN and send him a test file to see if it's up to par with what he wants.  That may save you a ton of time.
Autodesk Expert Elite
Revit Subject Matter Expert (SME)
Owner/FAA sUAS Pilot @ http://skyviz.io

ronjonp

  • Needs a day job
  • Posts: 7526
Re: Exploding multileaders but preserving the leaders?
« Reply #3 on: August 22, 2013, 10:00:32 AM »
Kinda off topic here .. but has anyone found a way to access the mtext object within an mleader without exploding?

Windows 11 x64 - AutoCAD /C3D 2023

Custom Build PC

Lee Mac

  • Seagull
  • Posts: 12905
  • London, England
Re: Exploding multileaders but preserving the leaders?
« Reply #4 on: August 22, 2013, 10:33:43 AM »
Kinda off topic here .. but has anyone found a way to access the mtext object within an mleader without exploding?

As far as I know, the MText content of an MLeader is not stored as a separate MText entity, but rather defined by the various DXF groups enclosed within the (300 . "CONTEXT_DATA{") section of the MLeader DXF data. I would assume that the MText entity is automatically generated using this data when the EXPLODE command is used.

ronjonp

  • Needs a day job
  • Posts: 7526
Re: Exploding multileaders but preserving the leaders?
« Reply #5 on: August 22, 2013, 11:15:08 AM »
Cool ... thanks Lee.

Windows 11 x64 - AutoCAD /C3D 2023

Custom Build PC

yarnstormer

  • Guest
Re: Exploding multileaders but preserving the leaders?
« Reply #6 on: August 22, 2013, 11:18:16 AM »
Are the resulting MLeader components all on the same layer?

If so, isolate the layer, then:

PEDIT > M > Select all Exploded MLeaders > J > Enter > Enter

ok that helps - a little buggy but it got it done with a little doctoring up after.
Where there are multiple leaders it get a little confused.
I don't export dgns. We are paying this guy to "make" our dgns that we will then send to the dot...I know I know...I just does what I'm told.

BlackBox

  • King Gator
  • Posts: 3770
Re: Exploding multileaders but preserving the leaders?
« Reply #7 on: August 22, 2013, 01:25:03 PM »
Kinda off topic here .. but has anyone found a way to access the mtext object within an mleader without exploding?

Kinda off topic here .. but has anyone found a way to access the mtext object within an mleader without exploding?

As far as I know, the MText content of an MLeader is not stored as a separate MText entity, but rather defined by the various DXF groups enclosed within the (300 . "CONTEXT_DATA{") section of the MLeader DXF data. I would assume that the MText entity is automatically generated using this data when the EXPLODE command is used.

FWIW -

Stemming from my work on this... There is actually a separate MText Property Object within an MLeader Typed entity (given ContentType == ContentType.MTextContent enum), it just has not been exposed to LISP... Which is where my appreciation for an MLeader's TextString Property stems from, as the code-behind this Property handles the necessary Transaction to access, and get/set the MText Object's TextString Property, without any additional end-user code... Just as compared to the same in .NET API get/set the string... It's really quite elegant.

Here's a small snippet from the linked project (which accepts DBText, MLeader, MText, etc., hence the switch case):

Code - C#: [Select]
  1. // <snip>
  2.  
  3.             try
  4.             {
  5.                 using (DocumentLock docLock = doc.LockDocument())
  6.                 {
  7.                     using (Transaction tr =
  8.                         db.TransactionManager.StartOpenCloseTransaction())
  9.                     {
  10.  
  11.                         foreach (ObjectId id in ids)
  12.                         {
  13.                             switch (id.ObjectClass.Name)
  14.                             {
  15.                                 case "AcDbMLeader":
  16.                                     mleader =
  17.                                         (MLeader)tr.GetObject(id, OpenMode.ForWrite);
  18.  
  19.                                     ContentType contentType = mleader.ContentType;
  20.  
  21.                                     if (contentType == ContentType.MTextContent)
  22.                                     {
  23.                                         mtext = mleader.MText;
  24.  
  25.                                         // use the texteditor where possible
  26.                                         if (strCase.Equals((int)StringCase.Lower) |
  27.                                                 strCase.Equals((int)StringCase.Upper)
  28.                                             )
  29.                                             ChangeCaseUsingTextEditor(mtext, strCase);
  30.  
  31.                                         // texteditor does not support sentence, title, or toggle
  32.                                         else
  33.                                             mtext.Contents = mtext.Contents.ToCase(strCase);
  34.                                        
  35.                                         mleader.MText = mtext;
  36.                                     }
  37.  
  38.                                     //// nested block attributes:
  39.                                     //else if (contentType == ContentType.BlockContent)
  40.                                     //{
  41.                                     //}
  42.  
  43.                                     break;
  44.  
  45.                                 case "AcDbMText":
  46.                                     mtext =
  47.                                         (MText)tr.GetObject(id, OpenMode.ForWrite);
  48.  
  49.                                     // use the texteditor where possible
  50.                                     if (strCase.Equals((int)StringCase.Lower) |
  51.                                             strCase.Equals((int)StringCase.Upper)
  52.                                         )
  53.                                         ChangeCaseUsingTextEditor(mtext, strCase);
  54.  
  55.                                     // texteditor does not support sentence, title, or toggle
  56.                                     else
  57.                                         mtext.Contents = mtext.Contents.ToCase(strCase);
  58.  
  59.                                     break;
  60.  
  61.                                 case "AcDbText":
  62.                                     text =
  63.                                         (DBText)tr.GetObject(id, OpenMode.ForWrite);
  64.  
  65.                                     text.TextString = text.TextString.ToCase(strCase);
  66.  
  67.                                     break;
  68.  
  69.                                 default:
  70.                                     break;
  71.                             }
  72.  
  73.                         }
  74.  
  75.                         tr.Commit();
  76.                     }
  77.                 }
  78.             }
  79.             catch
  80.             {
  81.             }
  82.  
  83. // <snip>
  84.  

For those who may be interested... The System.String Extension Methods used above can be found here.

Cheers



/OffTopic
"How we think determines what we do, and what we do determines what we get."

BlackBox

  • King Gator
  • Posts: 3770
Re: Exploding multileaders but preserving the leaders?
« Reply #8 on: August 22, 2013, 01:29:27 PM »
Are the resulting MLeader components all on the same layer?

If so, isolate the layer, then:

PEDIT > M > Select all Exploded MLeaders > J > Enter > Enter

ok that helps - a little buggy but it got it done with a little doctoring up after.
Where there are multiple leaders it get a little confused.
I don't export dgns. We are paying this guy to "make" our dgns that we will then send to the dot...I know I know...I just does what I'm told.

I think it's silly that exploding an MLeader (with Mtext content) results in an MText entity, and exploded Leader(s), frankly.

You might consider looking into an MLeader's GetLeaderLineVertices Method, to essentially recreate an actual Leader entity, rather than just joining the resultant linework, etc.

HTH
"How we think determines what we do, and what we do determines what we get."

BlackBox

  • King Gator
  • Posts: 3770
Re: Exploding multileaders but preserving the leaders?
« Reply #9 on: August 22, 2013, 01:51:02 PM »
Are the resulting MLeader components all on the same layer?

If so, isolate the layer, then:

PEDIT > M > Select all Exploded MLeaders > J > Enter > Enter

ok that helps - a little buggy but it got it done with a little doctoring up after.
Where there are multiple leaders it get a little confused.
I don't export dgns. We are paying this guy to "make" our dgns that we will then send to the dot...I know I know...I just does what I'm told.

I think it's silly that exploding an MLeader (with Mtext content) results in an MText entity, and exploded Leader(s), frankly.

You might consider looking into an MLeader's GetLeaderLineVertices Method, to essentially recreate an actual Leader entity, rather than just joining the resultant linework, etc.

HTH

Here's a quickly written sub-function, to extract the vertices for each of the two possible Leader indices (0 == All Leaders on Left, 1 == All Leaders on Right), and returns a list of pairs, where ((<LeaderLineIndex> <LeaderLineVertices>)):

Code - Auto/Visual Lisp: [Select]
  1.  
  2. (defun bbox:GetLeaderLineVertices (mleader / indexes vertices)
  3.   ;; Example:
  4.   ;;    (bbox:GetLeaderLineVertices mleader)
  5.   ;;
  6.   ;; Return:
  7.   ;;    ((<LeaderLineIndex> <LeaderLineVertices>))
  8.   (foreach i '(0 1)
  9.     (if (setq indexes (vlax-invoke mleader 'getleaderlineindexes i))
  10.       (foreach index indexes
  11.         (setq vertices
  12.                (cons
  13.                  (cons
  14.                    index
  15.                    (vlax-invoke
  16.                      mleader
  17.                      'getleaderlinevertices
  18.                      index
  19.                    )
  20.                  )
  21.                  vertices
  22.                )
  23.         )
  24.       )
  25.     )
  26.   )
  27.   (reverse vertices)
  28. )
  29.  

... You should be able to use this to iterate a selection of one or more MLeaders, extract their respective LeaderLineVertices, create a Leader object for each, and/or explode the MLeader (being sure to catch and delete all resultant Line, and Solid entities), or simply create a new MText entity in the same placement and delete the MLeader itself.

Again, HTH
"How we think determines what we do, and what we do determines what we get."

BlackBox

  • King Gator
  • Posts: 3770
Re: Exploding multileaders but preserving the leaders?
« Reply #10 on: August 22, 2013, 04:57:28 PM »
Ok I know it's a bad bad idea to explode multileaders but I am giving my civil 3d dwgs to a microstation user for conversion and he has asked that I explode them. He has also asked that I pedit the leaders back into polylines - which turn into separate entities when you explode the multileaders. He is ok with the resulting multiline text from exploding the multileaders.

Here's a brute force routine which combines what you're already doing (exploding the MLeaders), with Lee's original advice to use PEDIT:

Code - Auto/Visual Lisp: [Select]
  1. (defun c:FOO (/ ss e ss2)
  2.  
  3.   (if (setq ss (ssget "_:L" '((0 . "MULTILEADER"))))
  4.     (progn
  5.       (command "._undo" "begin")
  6.       (setq e (entlast))
  7.       (command "._explode" ss)
  8.       (setq ss2 (ssadd))
  9.       (while (and (setq e (entnext e))
  10.                   (= "LINE" (cdr (assoc 0 (entget e))))
  11.              )
  12.         (setq ss2 (ssadd e ss2))
  13.       )
  14.       (command "._pedit" "multiple" ss2 "" "join" 0.0 "")
  15.       (command "._undo" "end")
  16.     )
  17.   )
  18.   (princ)
  19. )
  20.  



Inspired by this thread, I've also refined my earlier sub-function to return LeaderLine pairs, where the second element is a list of individual point lists, rather than the single list of coordinates. I have also started but have not yet finished a routine to effectively 'Burst Mleaders' into MText & (associated) Leader(s), but will post when done.

Cheers
« Last Edit: August 22, 2013, 05:27:42 PM by BlackBox »
"How we think determines what we do, and what we do determines what we get."

Lee Mac

  • Seagull
  • Posts: 12905
  • London, England
Re: Exploding multileaders but preserving the leaders?
« Reply #11 on: August 22, 2013, 05:23:30 PM »
Code - Auto/Visual Lisp: [Select]
  1. (defun c:FOO (/ ss e ss2)
  2.  
  3.   (if (setq ss (ssget "_:L" '((0 . "MULTILEADER"))))
  4.     (progn
  5.       (command "._undo" "begin")
  6.       (setq e (entlast))
  7.       (command "._explode" ss)
  8.       (setq ss2 (ssadd))
  9.       (while (setq e (entnext e)) (setq ss2 (ssadd e ss2)))
  10.       (command "._pedit" "multiple" ss2 "" "join" 0.0 "")
  11.       (command "._undo" "end")
  12.     )
  13.   )
  14.   (princ)
  15. )
  16.  

Be careful when (entlast) is an attributed block or 2D/3D polyline.

BlackBox

  • King Gator
  • Posts: 3770
Re: Exploding multileaders but preserving the leaders?
« Reply #12 on: August 22, 2013, 05:25:54 PM »

Be careful when (entlast) is an attributed block or 2D/3D polyline.

Good catch; been a while since I did brute force Command calls.

... It (the code) should filter for "LINE" in this case. Code revised.

Cheers, mate.
"How we think determines what we do, and what we do determines what we get."

Lee Mac

  • Seagull
  • Posts: 12905
  • London, England
Re: Exploding multileaders but preserving the leaders?
« Reply #13 on: August 22, 2013, 05:42:45 PM »

Be careful when (entlast) is an attributed block or 2D/3D polyline.

Good catch; been a while since I did brute force Command calls.

... It (the code) should filter for "LINE" in this case. Code revised.

Cheers, mate.

Cheers - though, not so fast - what if the first entity added to the database following the explode is not a LINE...

BlackBox

  • King Gator
  • Posts: 3770
Re: Exploding multileaders but preserving the leaders?
« Reply #14 on: August 22, 2013, 07:46:10 PM »

Be careful when (entlast) is an attributed block or 2D/3D polyline.

Good catch; been a while since I did brute force Command calls.

... It (the code) should filter for "LINE" in this case. Code revised.

Cheers, mate.

Cheers - though, not so fast - what if the first entity added to the database following the explode is not a LINE...

In addition to that, has anyone tried using (command "._explode" ss) on a selection set of multiple MLeaders, where at least one has BlockContent (instead of MText)?

Not sure if it's something here with my ADN license, but MText ContentTypes are exploding, and Block is/are not... Curious too that there is no Explode Method available (which would make identifying only what entities have been added really simple).
"How we think determines what we do, and what we do determines what we get."

irneb

  • Water Moccasin
  • Posts: 1794
  • ACad R9-2016, Revit Arch 6-2016
Re: Exploding multileaders but preserving the leaders?
« Reply #15 on: August 23, 2013, 02:00:14 AM »
BB, as far as I remember you could get the resulting entities after exploding using a ssget with the "_P" modifier, so you need not go about the entnext loop to add into a new selection set. A bit unintuitive, since the explode results in "new" entities, and "Previous" selection (to me) means "what you selected previously". But then again the same thing happens with the measure and divide commands  :?

Not that I think it's "stupid", it's actually quite useful. Just that it tends to be missed since that's not what you expect should happen.

Edit: I'd actually think something like a "Result" selection modifier would be more suitable here (that is as opposed to the "Previous"). Something like my old code from here: http://forums.augi.com/showthread.php?81175-select-result-lisp-modification&p=850195&viewfull=1#post850195
« Last Edit: August 23, 2013, 02:07:42 AM by irneb »
Common sense - the curse in disguise. Because if you have it, you have to live with those that don't.

Lee Mac

  • Seagull
  • Posts: 12905
  • London, England
Re: Exploding multileaders but preserving the leaders?
« Reply #16 on: August 23, 2013, 06:19:19 AM »
FWIW, and to follow-up my comments on BlackBox's code, here is how I would approach the command version of the program:

Code - Auto/Visual Lisp: [Select]
  1. (defun c:mlex ( / ent new sel tmp val var )  
  2.     (if (setq sel (ssget "_:L" '((0 . "MULTILEADER"))))
  3.         (progn
  4.             (command "_.undo" "_be")
  5.             (setq var '(cmdecho qaflags peditaccept)
  6.                   val  (mapcar 'getvar var)
  7.                   ent  (entlast)
  8.                   new  (ssadd)
  9.             )
  10.             (mapcar 'setvar var '(0 1 1))
  11.             (while (setq tmp (entnext ent))
  12.                 (setq ent tmp)
  13.             )
  14.             (command "_.explode" sel "")
  15.             (while (setq ent (entnext ent))
  16.                 (if (wcmatch (cdr (assoc 0 (entget ent))) "ARC,LINE,LWPOLYLINE")
  17.                     (ssadd ent new)
  18.                 )
  19.             )
  20.             (command "_.pedit" "_m" new "" "_j" "" "")
  21.             (mapcar 'setvar var val)
  22.             (command "_.undo" "_e")
  23.         )
  24.     )
  25.     (princ)
  26. )

A few notes:

Code - Auto/Visual Lisp: [Select]
  1. (defun c:FOO (/ ss e ss2)
  2.  
  3.   (if (setq ss (ssget "_:L" '((0 . "MULTILEADER"))))
  4.     (progn
  5.       (command "._undo" "begin")
  6.       (setq e (entlast))
  7.       (command "._explode" ss)
  8.       (setq ss2 (ssadd))
  9.       (while (and (setq e (entnext e))
  10.                   (= "LINE" (cdr (assoc 0 (entget e))))
  11.              )
  12.         (setq ss2 (ssadd e ss2))
  13.       )
  14.       (command "._pedit" "multiple" ss2 "" "join" 0.0 "")
  15.       (command "._undo" "end")
  16.     )
  17.   )
  18.   (princ)
  19. )
  20.  
  • Localisation prefixes are still required for command keywords, e.g. "_m"
  • The EXPLODE command will only process a single entity unless the QAFLAGS system variable is set to 1
  • The PEDIT command will issue the prompt 'Convert Lines, Arcs and Splines to polylines' unless the PEDITACCEPT system variable is set to 1
  • Since pickset variables are essentially pointers to the pickset (similar to ename & vla-object variables), there is no need to re-assign the result of an ssadd / ssdel operation to the pickset variable.

irneb

  • Water Moccasin
  • Posts: 1794
  • ACad R9-2016, Revit Arch 6-2016
Re: Exploding multileaders but preserving the leaders?
« Reply #17 on: August 23, 2013, 07:30:39 AM »
Hope you don't mind Lee & BB, here's my variant which doesn't need to step through each entity after those when Explode finished.
Code - Auto/Visual Lisp: [Select]
  1. (defun c:mlex (/ sel val var)
  2.   (if (setq sel (ssget "_:L" '((0 . "MULTILEADER"))))
  3.     (progn (command "_.undo" "_be")
  4.            (setq var '(cmdecho qaflags peditaccept)
  5.                  val (mapcar 'getvar var)
  6.            )
  7.            (mapcar 'setvar var '(0 1 1))
  8.            (command "_.explode" sel "")
  9.            (if (setq sel (ssget "_P" '((0 . "ARC,LINE,LWPOLYLINE"))))
  10.              (command "_.pedit" "_m" sel "" "_j" "" "")
  11.            )
  12.            (mapcar 'setvar var val)
  13.            (command "_.undo" "_e")
  14.     )
  15.   )
  16.   (princ)
  17. )
Edit: Nice setvar method there Lee  8-)
« Last Edit: August 23, 2013, 07:37:23 AM by irneb »
Common sense - the curse in disguise. Because if you have it, you have to live with those that don't.

Lee Mac

  • Seagull
  • Posts: 12905
  • London, England
Re: Exploding multileaders but preserving the leaders?
« Reply #18 on: August 23, 2013, 07:42:44 AM »
Thanks Irné, I think the OP has many methods to consider now :-)

irneb

  • Water Moccasin
  • Posts: 1794
  • ACad R9-2016, Revit Arch 6-2016
Re: Exploding multileaders but preserving the leaders?
« Reply #19 on: August 23, 2013, 07:43:41 AM »
Edit: Nice setvar method there Lee  8-)
I'm definitely going to try something like this in the future:
Code - Auto/Visual Lisp: [Select]
  1. (defun resetvars (names values / old)
  2.   (setq old (mapcar 'getvar names))
  3.   (mapcar 'setvar names values)
  4.   (list names old)
  5. )
  6.  
  7. (defun c:foo (/ old)
  8.   (setq old (resetvars '(cmdecho qaflags peditaccept)
  9.                        '(0 1 1)
  10.             )
  11.   )
  12.   ;; Do your stuff here
  13.   (apply 'resetvars old)
  14.   (princ)
  15. )
Common sense - the curse in disguise. Because if you have it, you have to live with those that don't.

irneb

  • Water Moccasin
  • Posts: 1794
  • ACad R9-2016, Revit Arch 6-2016
Re: Exploding multileaders but preserving the leaders?
« Reply #20 on: August 23, 2013, 07:53:13 AM »
In addition to that, has anyone tried using (command "._explode" ss) on a selection set of multiple MLeaders, where at least one has BlockContent (instead of MText)?
Yes, the block itself is not exploded. So the command version of this works as advertised.
Common sense - the curse in disguise. Because if you have it, you have to live with those that don't.

Lee Mac

  • Seagull
  • Posts: 12905
  • London, England
Re: Exploding multileaders but preserving the leaders?
« Reply #21 on: August 23, 2013, 07:56:53 AM »
I'm definitely going to try something like this in the future:
Code - Auto/Visual Lisp: [Select]
  1. (defun resetvars (names values / old) ...

Nice progression Irné -

A minor caveat: just ensure that any undo marks lie outside of the system variable changes (i.e. the system variable changes are enclosed within the undo marks) since an undo operation will revert the last undo group, but also any changes following the last undo group, thereby undoing the operation to reset the system variables.

irneb

  • Water Moccasin
  • Posts: 1794
  • ACad R9-2016, Revit Arch 6-2016
Re: Exploding multileaders but preserving the leaders?
« Reply #22 on: August 23, 2013, 08:01:02 AM »
A minor caveat: just ensure that any undo marks lie outside of the system variable changes
Yep! That's one of the reasons I prefer using the vla method to set undo marks - at least then it's possible to hide even that from the command-line. I suppose you could do it through 3 separate setvar sets, but IMO that's just being silly :laugh:
Common sense - the curse in disguise. Because if you have it, you have to live with those that don't.

BlackBox

  • King Gator
  • Posts: 3770
Re: Exploding multileaders but preserving the leaders?
« Reply #23 on: August 23, 2013, 12:09:18 PM »
  • Localisation prefixes are still required for command keywords, e.g. "_m"

Perhaps I am not understanding you fully, and if so please educate me, but prefixes aren't required for the command keywords to work... In fact the use of prefixes can break code portability, depending on which command and/or version:

http://forums.augi.com/showthread.php?101566-Help!-Fillet-stopped-working-(in-2009-or-higher)



Cheers

[Edit] - Here's a quick observation of what is being done whilst monitoring Document Events via MgdDbg:

Code - Text: [Select]
  1. Command: _MgdDbgEvents
  2.  
  3. Application Events Turned On ...
  4.  
  5. Document Events Turned On ...
  6.  
  7. [Doc Event] : Command Ended             : MGDDBGEVENTS
  8. Command: (command "._undo" "_be")
  9.  
  10. [Doc Event] : Lisp will Start           : (command "._undo" "_be")._undo
  11. [Doc Event] : Command will Start        : UNDOCurrent settings: Auto = On,
  12. Control = All, Combine = Yes, Layer = Yes
  13. Enter the number of operations to undo or [Auto/Control/BEgin/End/Mark/Back]
  14. <1>: _be
  15. [Doc Event] : Command Ended             : UNDO
  16. Command: nil
  17.  
  18. Command:
  19. [Doc Event] : Lisp ended               (command "._undo" "begin")
  20.  
  21. [Doc Event] : Lisp will Start           : (command "._undo" "begin")._undo
  22. [Doc Event] : Command will Start        : UNDOCurrent settings: Auto = On,
  23. Control = All, Combine = Yes, Layer = Yes
  24. Enter the number of operations to undo or [Auto/Control/BEgin/End/Mark/Back]
  25. <1>: begin
  26. [Doc Event] : Command Ended             : UNDO
  27. Command: nil
  28.  
  29. Command:
  30. [Doc Event] : Lisp ended
  31.  
« Last Edit: August 23, 2013, 01:59:59 PM by BlackBox »
"How we think determines what we do, and what we do determines what we get."

owenwengerd

  • Bull Frog
  • Posts: 451
Re: Exploding multileaders but preserving the leaders?
« Reply #24 on: August 23, 2013, 02:03:48 PM »
BB, I think you're confusing prefixes. The hyphen is not a generic prefix, it's just a naming convention. The underscore is a true prefix, and it is required on command options in order to be locale independent.

BlackBox

  • King Gator
  • Posts: 3770
Re: Exploding multileaders but preserving the leaders?
« Reply #25 on: August 23, 2013, 03:35:51 PM »
BB, I think you're confusing prefixes. The hyphen is not a generic prefix, it's just a naming convention. The underscore is a true prefix, and it is required on command options in order to be locale independent.

Hi Owen,

Thanks for your response.

Admittedly, I have no idea how many, or few for that matter, Command options Autodesk has even changed (as they did in the above linked thread, back in 2009 release)... I'd even be willing to speculate that it's very few.

Generally speaking, one who codes for others in multiple countries, etc. (as someone such as yourself, or Lee often does), will appropriately use localisation prefixes as described... And if / when Autodesk makes change(s) again, which breaks said code, changes will be made at that time. SDLC and all that.

Whereas, code that need only account for a single language, and uses spelled out Command options, will not break in the same version that breaks portability for the localised code. That's all I was trying to communicate... How one 'should' code is relative to one's product scope, IMO.

Cheers
"How we think determines what we do, and what we do determines what we get."

owenwengerd

  • Bull Frog
  • Posts: 451
Re: Exploding multileaders but preserving the leaders?
« Reply #26 on: August 23, 2013, 04:58:46 PM »
Whereas, code that need only account for a single language, and uses spelled out Command options, will not break in the same version that breaks portability for the localised code. That's all I was trying to communicate... How one 'should' code is relative to one's product scope, IMO.

You are mistaken in your assertion that not using the underscore prefix helps to avoid breaking changes. There is no such case. Therefore, writing locale-friendly code is always better.

BlackBox

  • King Gator
  • Posts: 3770
Re: Exploding multileaders but preserving the leaders?
« Reply #27 on: August 23, 2013, 05:47:35 PM »
Whereas, code that need only account for a single language, and uses spelled out Command options, will not break in the same version that breaks portability for the localised code. That's all I was trying to communicate... How one 'should' code is relative to one's product scope, IMO.

You are mistaken in your assertion that not using the underscore prefix helps to avoid breaking changes. There is no such case. Therefore, writing locale-friendly code is always better.

I've already cited one such case (linked above), and clearly pointed out the infrequency of such happening often... I'm not arguing what is better here, simply pointing out the fact that using localisation has in inherent flaw as designed by Autodesk.

This potential issue is also (albeit surprisingly) documented as an example under INITCOMMANDVERSION in the help.



Here's an example, with and without initialized command version, where both use localised Command option, and only one is successful:

Code - Text: [Select]
  1. Command: (progn (initcommandversion 1) (command "._fillet" "_n" pause))
  2. fillet
  3. Current settings: Mode = TRIM, Radius = 0.0000
  4. Select first object or [uNdo/Polyline/Radius/Trim/mUltiple]: _n
  5. Command has been completely undone.
  6.  
  7. Select first object or [uNdo/Polyline/Radius/Trim/mUltiple]: *Cancel*
  8.  
  9. Command: ; error: Function cancelled
  10.  
  11. Command: (progn (initcommandversion 2) (command "._fillet" "_n" pause))
  12. fillet
  13. Current settings: Mode = TRIM, Radius = 0.0000
  14. Select first object or [Undo/Polyline/Radius/Trim/Multiple]: _n
  15.  
  16. *Invalid selection*
  17. Expects a point or
  18. Window/Last/Crossing/BOX/Fence/WPolygon/CPolygon/Undo/Polyline/Radius/Trim
  19. ; error: Function cancelled
  20.  
  21. Select first object or [Undo/Polyline/Radius/Trim/Multiple]: *Cancel*
  22.  
  23. Command:
  24.  



... Yet in the same version, also with and without initialized command version, spelling out the Command option (in lieu of using localised Command option) works in both:

Code - Text: [Select]
  1. Command: (progn (initcommandversion 1) (command "._fillet" "undo" pause))
  2. fillet
  3. Current settings: Mode = TRIM, Radius = 0.0000
  4. Select first object or [uNdo/Polyline/Radius/Trim/mUltiple]: undo
  5. Command has been completely undone.
  6.  
  7. Select first object or [uNdo/Polyline/Radius/Trim/mUltiple]: *Cancel*
  8.  
  9. Command: ; error: Function cancelled
  10.  
  11. Command: (progn (initcommandversion 2) (command "._fillet" "undo" pause))
  12. fillet
  13. Current settings: Mode = TRIM, Radius = 0.0000
  14. Select first object or [Undo/Polyline/Radius/Trim/Multiple]: undo
  15. Command has been completely undone.
  16.  
  17. Select first object or [Undo/Polyline/Radius/Trim/Multiple]: *Cancel*
  18.  
  19. Command: ; error: Function cancelled
  20.  



If you continue to insist that I am mistaken, that's fine, I respect your opinion, and kindly ask that you site your source so that I may educate myself where I am wrong... As what you have stated is not the behavior observed here, nor in my limited experience.

Cheers
"How we think determines what we do, and what we do determines what we get."

owenwengerd

  • Bull Frog
  • Posts: 451
Re: Exploding multileaders but preserving the leaders?
« Reply #28 on: August 23, 2013, 08:31:37 PM »
Your example demonstrates that (initcommandversion) changes the keywords to a command, but that has nothing whatever to do with the underscore prefix. If you want to create an example that demonstrates different behavior with or without the underscore prefix, then the two tests should be identical except for the underscore prefix. I hope that helps.

Lee Mac

  • Seagull
  • Posts: 12905
  • London, England
Re: Exploding multileaders but preserving the leaders?
« Reply #29 on: August 24, 2013, 09:03:12 AM »
BlackBox,

I respect the point you are trying to make, but I think we are talking about two different things -

To realise the necessity for the underscore prefix, you would need to run the test on both an English & non-English version of AutoCAD. Whether or not the keyword is shortened or written in full, without the underscore prefix the command will fail in the non-English version unless by chance the translated keyword uses the same option letter.

How one 'should' code is relative to one's product scope, IMO.

Up to a point; in this case, if compatibility with non-English versions of AutoCAD is achieved by simply inserting an underscore prefix, I see no reason to omit it.

BlackBox

  • King Gator
  • Posts: 3770
Re: Exploding multileaders but preserving the leaders?
« Reply #30 on: August 26, 2013, 08:21:54 AM »
... This, seemingly one of the many differences between this CAD production guy & amateur developer, and professional developers like yourself, and Owen... I appreciate your patience, while I struggle to wrap my head around this, guys.

Cheers
"How we think determines what we do, and what we do determines what we get."

Marc'Antonio Alessi

  • Swamp Rat
  • Posts: 1451
  • Marco
Re: Exploding multileaders but preserving the leaders?
« Reply #31 on: August 26, 2013, 08:35:19 AM »
...
Command: (progn (initcommandversion 1) (command "._fillet" "_n" pause))
Select first object or [uNdo/Polyline/Radius/Trim/mUltiple]: _n
...
Command: (progn (initcommandversion 2) (command "._fillet" "_n" pause))
Select first object or [Undo/Polyline/Radius/Trim/Multiple]: _n
...

uNdo vs. Undo

I use the entire option "_undo" and not an abbreviation to avoid this kind of problems in my italian/english programs.

irneb

  • Water Moccasin
  • Posts: 1794
  • ACad R9-2016, Revit Arch 6-2016
Re: Exploding multileaders but preserving the leaders?
« Reply #32 on: August 26, 2013, 08:56:56 AM »
I use the entire option "_undo" and not an abbreviation to avoid this kind of problems in my italian/english programs.
Exactly! In the same idiom as
in this case, if compatibility with non-English versions of AutoCAD is achieved by simply inserting an underscore prefix, I see no reason to omit it.
I see no reason to omit the underscore, neither do I see a reason to only send the capitalized letter of the option.

Sure it's less typing, but for a few less keystrokes you open yourself for issues later on when your code is running on another language ACad or even just a later / earlier version.
Common sense - the curse in disguise. Because if you have it, you have to live with those that don't.

owenwengerd

  • Bull Frog
  • Posts: 451
Re: Exploding multileaders but preserving the leaders?
« Reply #33 on: August 26, 2013, 10:00:59 AM »
I appreciate your patience, while I struggle to wrap my head around this, guys.

I've enjoyed watching you and other "amateurs" develop and grow. Just a few years ago, I was you. One of these days, you'll be the one whipping the young guys into shape.  :police:

BlackBox

  • King Gator
  • Posts: 3770
Re: Exploding multileaders but preserving the leaders?
« Reply #34 on: August 26, 2013, 10:26:23 AM »
I appreciate your patience, while I struggle to wrap my head around this, guys.

I've enjoyed watching you and other "amateurs" develop and grow. Just a few years ago, I was you. One of these days, you'll be the one whipping the young guys into shape.  :police:

That is incredibly kind, and encouraging, of you to say, Owen... If only I could find an employer that felt the same.

I do hope that you can appreciate that I was genuinely seeking a greater understanding here, and not (at least not intentionally) being argumentative... I'd like to believe that what little I know, I know well... But more importantly (to me), I wouldn't be where I am today, without the kindness of others to point, even if that meant offering me a swift kick, in the right direction.

Particularly as one of the 'young guys', I'd like to offer you a cheers, for the help you generously give this community (I'd offer you a dram in person, but for now a quick pic from this weekend will have to do :-))... Cheers:

"How we think determines what we do, and what we do determines what we get."

LE3

  • Guest
Re: Exploding multileaders but preserving the leaders?
« Reply #35 on: August 26, 2013, 10:35:21 AM »
^
BB.... Just to give you a real life example -- Owen gave me a lot of help and also samples and review it those for me, when I started into the C++/MFC/and ObjectARX, some years ago, now I work doing software, for one of the big/best companies in the US.

So keep there and learn every day. :)


Have fun!
Luis.-

BlackBox

  • King Gator
  • Posts: 3770
Re: Exploding multileaders but preserving the leaders?
« Reply #36 on: August 26, 2013, 10:44:10 AM »
^
BB.... Just to give you a real life example -- Owen gave me a lot of help and also samples and review it those for me, when I started into the C++/MFC/and ObjectARX, some years ago, now I work doing software, for one of the big/best companies in the US.

So keep there and learn every day. :)


Have fun!
Luis.-

Thank you for sharing, Luis... I'm very happy for you, and take your advice & encouragement to heart.  :-)

Cheers
"How we think determines what we do, and what we do determines what we get."

yarnstormer

  • Guest
Re: Exploding multileaders but preserving the leaders?
« Reply #37 on: March 20, 2014, 10:26:05 AM »
ya'll lost me on this thread...but wanted to pop in and say eureka I can just use the "burst" command to explode the mleader an not explode the leader. Mission accomplished.

Or you could write a bunch of complicated codey stuff...  :-D

BlackBox

  • King Gator
  • Posts: 3770
Re: Exploding multileaders but preserving the leaders?
« Reply #38 on: March 20, 2014, 11:05:52 AM »
... wanted to pop in and say eureka I can just use the "burst" command to explode the mleader an not explode the leader. Mission accomplished.

Curious... Just tried BURST Command in 2014 and MLeader is not a valid selection.
"How we think determines what we do, and what we do determines what we get."