Good idea Lee.
Off to play tennis but will take a look this afternoon. :-)
It looks very useful tool and clear to read .
Thanks for your great efforts . :-)
Is not it good idea to use vla-purgeall function instead of the command call ?
(nth *l (list "Utwórz blok anonimowy\n" "Make annonymous block\n"))
- maybe option to delete some dictionary (only for experts)Your line 60 etc:Code - Auto/Visual Lisp: [Select]Could becomeCode - Auto/Visual Lisp: [Select]
Why (only) remove anon groups? They can be as useful/useless as named groups.
Redundant groups...
Some portions of the program would have to be run repeatedly. Block defs can become empty if block refs of empty blocks have been deleted. Modularize?
Perhaps (also) start with purging. That way the program will potentially have to analyse/do less.
really great idea Lee.
- create dcl (on the fly) to select what to delete/clean and what not
- maybe multilanguage option likeCode: [Select](nth *l (list "Utwórz blok anonimowy\n" "Make annonymous block\n"))
- maybe option to delete some dictionary (only for experts)
You might like to consider issues coming from older Legacy drawings, or other cad apps that generate .dwg. An example of this is empty text strings. These used to be created in AutoCAD by editing some TEXT/MTEXT and deleting all the text in the dialogue, which resulted in an empty text string. This was fixed in later versions of AutoCAD, but is still possible in BricsCAD, and your likely to strike if your working on older drawings.
I've also seen bad implementation of valid objects on drawings. such as drawing a property boundary using the letter "X" instead of using an appropriate linetype.
Maybe your routine needs to Audit first, provide the user with a list of potential issues, and allow them to select which ones they wish to act on.
I haven't checked, but you used to have issues with purging empty layers if you had set viewport related properties from within a paperspace viewport.
My logic was that anonymous groups are more likely to be automatically generated by another program, or inadvertently generated by an unsuspecting user;
QuoteMy logic was that anonymous groups are more likely to be automatically generated by another program, or inadvertently generated by an unsuspecting user;
I have written programs which generate "anonymous" groups, by design.
I use also a third party application which has a use for one entity groups, because it associates additional information with them.
Suggest (as others have) that you provide options as to what gets "cleaned up."
If you want, I did kind of program.
You can pick ideas here (http://patrick.blog-cao.com/2010/10/14/jav-v3-00/)
It remains only to translate it into English
The only problem is that I have not mastered enough English to do the translation.
And as I have online, I was wondering what software did you animate your pictures to better explain your lisps
With a quick glance, I did not see where regapps were getting purged. IN the past I have had to specifically call the purging of those but with the new fancy code it might be already taken care of.
**EDIT**
maybe throw in a file save? :| :|
Since this will be a general program for all to use, multilanguage support will be a necessity - though, I'll certainly need your's (& Google's) help with this!of course will be happy to help with polish translation.
I've tried via Dictionaries. I've used sometimes simply '(dictremove (namedobjdict) "ACAD_SCALELIST")' and file size decreased quite a lot. But, I've gone a little bit further, and I've tried this now:I'd be extremely careful about simply erasing the scales dictionary or any one scale from that. And you will keep on seeing them in the scales list because ACad tries to fix this possible crash situation of having no scales to display.
I've tried via Dictionaries. I've used sometimes simply '(dictremove (namedobjdict) "ACAD_SCALELIST")' and file size decreased quite a lot. But, I've gone a little bit further, and I've tried this now:I'd be extremely careful about simply erasing the scales dictionary or any one scale from that. And you will keep on seeing them in the scales list because ACad tries to fix this possible crash situation of having no scales to display.
You need at least one scale left in the DWG. And you actually shouldn't delete scales which has been applied to something - that tends to crash acad. Erasing all scales' dictionaries do not test for scales being applied before deleting them. Anyhow thus use the Reset option in the scalelistedit command - that's a lot safer. Otherwise you'll need to step through everything in the DWG to see which scales can be erased.
My problems with scales came from a DWG file I recieved from a partner, used as a XREF in a project, in which I detected 6832 different scales (I suppose inherited from other drawings). Every drawing with that XREF attached took about 3 minutes to open ( :realmad: !!!).This is why I'm saying ADesk are idiots with the scales list (http://forums.augi.com/showthread.php?74324-Scale-List-Nightmares!!&p=975210&viewfull=1#post975210). They don't have a clue about what a scale-name is supposed to be. They should never have written the extra code to affix that _XREF to the scale's name when loaded from a xref - there's no benefit to it and it causes this exponential growth in scales.
Just another curiosity 'to whom it may concern': I've used "scalelistedit" (NOT "-scalelistedit") against those 6832 scales, and it appears an error message saying "Matrix index out of range"... :? Of course, "-scalelistedit", option "Reset", works properly.That's because it's trying to load all 6832 names into the list for display in the dialog. And that listbox has a maximum length.
Think it is not a good idea to put all purge routines in single command because lisp is too slow even if compiled. On huge drawings it will freeze or even crash autocad
There are a number of precautions one need take when using wblock * (or -ExportToAutoCAD yada) to ensure things don't FUBAR on you. This includes making sure the WCS is active in all paper-space resident viewports and model-space before performing the export. Failure to ensure will sometimes produce wack-a-doodle, undersirable results ...
/Red Sector A
((lambda (dict)
(if (dictsearch (namedobjdict) dict)
(progn
(dictremove (namedobjdict) dict)
(princ "\nDGN Line Styles Removed")
)
(princ "\nDGN Line Styles not found")
)
)
"ACAD_DGNLINESTYLECOMP"
) ;Delete DGN
(vl-load-com)
(setq doc (vla-get-ActiveDocument (setq *acad (vlax-get-Acad-Object))))
(progn
(vlax-for layer (vla-get-Layers doc)
(vl-catch-all-apply
'vla-Remove
(list (vla-GetExtensionDictionary layer)
"ADSK_XREC_LAYER_RECONCILED"
)
) ;(vl-catch-all-apply 'vla-Delete (list (vla-GetExtensionDictionary layer)))
)
(princ "\nRECONCILED Layers Removed")
) ; Delete reconciled filter
This code deletes all non-acad dictionaries. ...I would say it is important to make differences between "Purging" (not used) things and deleting things.
This code deletes all non-acad dictionaries...
Sometimes we have no choise to be or not to be a chicken. Life is also dangerous, it cause death.This code deletes all non-acad dictionaries...
I HIGHLY advise against the sledge hammer approach. For example, if you delete "Ks_ShapeRefDictionary" you are in for a world of pain and quite possibly a lynching. Not all non acad dictionaries are evil and many of them are essential. In the case of "Ks_ShapeRefDictionary" it's essential for proper loading/display even if you are a mere consumer of a model (rather than the owner/maintainer).
tl:dr: Don't be the guy who knows enough to be dangerous.
This isn't about being a chicken. It's about judicious use of technique. As for espousing the merits of cleaning files you're preaching to the choir. :)Some drawings like a boat floating from hands to hands. When drawing I recieve freezes my autocad I extremely need to clean all damn garbage to do my work.
< .. > And of course I need to explode all proxy. So don't say me about danger. I have no idea on how to be careful :P
Make sure to clean up xrefs that aren't loading and images that are no longer being loaded.
(VL-CATCH-ALL-APPLY
'(lambda()
(mapcar '(lambda(x)
(dictremove (namedobjdict) x)
)
'(
"ACAD_DATALINK"
"ACAD_DGNLINESTYLECOMP"
"ACAD_VBA"
)
)
)
)
2. Removes the history from 3D solid primitives (_brep _all (http://docs.autodesk.com/ACD/2010/ENU/AutoCAD%202010%20User%20Documentation/index.html?url=WS1a9193826455f5ffa23ce210c4a30acaf-4d62.htm,topicNumber=d0e207473))(vlax-for blk_def (vla-get-blocks adoc)
(if (equal (vla-get-isxref blk_def) :vlax-false)
(vlax-for subent blk_def
(if (= (vla-get-objectname subent) "AcDb3dSolid")
(setq ent_lst (cons (vlax-vla-object->ename subent) ent_lst))
) ;_ end of if
) ;_ end of vlax-for
) ;_ end of if
) ;_ end of vlax-for
(foreach ent ent_lst
(if (and (cdr (assoc 350 (entget ent)))
(not (vl-catch-all-error-p
(vl-catch-all-apply
(function
(lambda () (entget (cdr (assoc 350 (entget ent)))))
) ;_ end of function
) ;_ end of vl-catch-all-apply
) ;_ end of vl-catch-all-error-p
) ;_ end of not
(entget (cdr (assoc 350 (entget ent))))
) ;_ end of and
(entdel (cdr (assoc 350 (entget ent))))
) ;_ end of if
) ;_ end of foreach
My take is if you're cleaning up files for internal use ( background ) .. Blast the smithereens out of them. ;) . if you're sharing use caution.