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

0 Members and 1 Guest are viewing this topic.

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: 12906
  • 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: 12906
  • 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: 12906
  • 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: 12906
  • 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.