I wouldn't have a clue - Andre's lisp is way beyond me. However, I have been continuing on with multiple visibility blocks by using the 2011 version of the program (v1.3, 24.10.09) in AutoCAD 2011. I can then go ahead and use the finished blocks in AutoCAD 2012-2013 without issues. I have written a little epilogue to the program in order to simplify calling the functions. It is a lot easier to do something like this so that you are not encumbered with entering autolisp lines at the command prompt. I keep a printout of this next to my workstation so I can refer to what the commands do - it simplifies using the program sugnificantly.
;;;turn functions into commands with simple calls
(defun c:EGO () (eval_graf_output));get ACAD_EVALUATION_GRAPH dictionary from the block editor space
(defun c:VA () (visibility_add));add a new Visibility Set parameter
(defun c:VU () (visibility-up));set selected Visibility Set as current
(defun c:NCVS () (tecuch_visibility));find name of current visibility state
(defun c:GON () (eddedd));switch on grips of all the elements of the current Visibility Set
(defun c:RFV () (element-sel-current-del));remove selected elements from the current Visibility Set
(defun c:RAFV () (element-all-current-del));remove all elements from the current Visibility Set
(defun c:AVS () (element-sel-current-insert));add selected elements to current Visibility Set
(defun c:VC () (Visibility_clear));complete cleaning of current state from all the elements, dynamic properties and states
(defun c:'SVAA () (properties_add_all_visibility));set visibility of all the dynamic properties and grips in all the states of all Visibility Sets
(defun c:BSVS () (move-to-visibilityset));batch set visibility of selected entities in several chosen states of the current visibility set
[note: Remove ' from before SVAA command defun - the discussion group sees the colon and capitol S as code to add a smiley!]
I'll include the instructions (copied and edited for my changes), as well as the tips that I've learned after using this for a year now to create hundreds of Multipe Visibility Dynamic Blocks.
------------------------------------------------------------------------------------------------------
Elements:
Lines, arcs, splines, attributes, text, etc.
1) Place all the elements. The location doesn't matter at first, so make them easy to select by not stacking things on top of each other.
2) Add all the parameters/actions you want - DO NOT add any visibility states or lookups yet. Make sure your actions affect the things you want, and don't affect the things you don't want them to.
3) Load visibility-add-eng.lsp.
4) Add a visibility parameter using VA(visibility_add). Rename the parameter accordingly.
5) Set this new visibility parameter active using VU(visibility-up). There is a little problem with the program here. When you have one visibility parameter active and you set a new one active, it gets hung up. Use the visibility state pulldown and select a state. Note the command line will ask you for a visibility state. Type ? to see those available, then type in any name you want.
6) Add the states to the list of visibilities - DO NOT change the visibility of anything yet.
7) Using RFV(element-sel-current-del) select all the elements you do not want to be affected when you change this particular visibility state. I do this by typing RFV, then entering ALL for the selection set, then removing my choice entities from the ALL selection set so only my choice entities get into the visibility set. For example: If I'm working on the "actuator" visibility states, I don't want my valve type to change if a person wants to use a different actuator, therefore, I will select every element that is not an actuator.
8) Now you can make elements visible or invisible in the states you've defined. Do not bother changing the visibility of the elements you've removed.
NOTE: if you draw a new object or copy something, it will not be removed
from any visibility sets.
9) Repeat steps 4 thru 8.
TIPS:
You can add new entities to an existing MVDB (multiple visibility dynamic block) by inserting, copy pasting or drawing them, then using SVAA to include them in the visibility sets. I find that this seems to add the new entities to every visibility set, so I have to make each one active (VU) and make unneeded entities invisible, or RVF them.
If after you add an additional visual parameter, you have trouble setting it current, just test the block and close the test window. VU will now accept it as the current state.
I can get a misbehaving block to recover sometimes by testing it in the test window, renaming it there with the rename command, copy-pasting it out and pasting it into a new drawing where I can open it in the block editor, reload the visibility engine and it will often work again.
Although we are not supposed to be able to, I can add a block table (block properties table) and still get multiple view parameters to work. The trick is to add the table and not populate it with anything but one simple parameter – something like a linear move, just to get the grip to show up. Then once you have the block functioning correctly with every other parameter, test the block, rename it as a “build mule” (a good copy that you can fall back and restart on) in the test window, copy that mule out to a safe drawing, then go back to the block in the editor and populate the table with all the parameters you need. MVDB’s cannot tolerate user parameters (the kind that block property tables allow you to add ), so once you add some, you will not be able to do further editing unless you open that block property table, delete the user parameters you made, wipe out the data in the table (I copy-paste my data to an excel spreadsheet for safekeeping, and paste it back in once I have the columns redefined properly), then close the block property table and use the parameter manager to delete the user parameters. Now you can edit the MVDB further and when you are ready, add the user parameters and data (from excel) back in and test. Once a block table is populated, the block will cease to function properly if further editing occurs, but further editing can be accomplished with the workaround.
I always use the test window and then rename my MVDB and then copy-paste out to my master drawing (called my dynamic block gene pool). The gene pool contains every MVDB I have in various stages of working iteration until completion. I have found this to be the best way to back up since using this lisp a lot can cause crashes when you try new ideas sometimes. I crash it 3 or 4 times a week, sometimes in a problem block, I might crash AutoCAD 10 times that day. But that’s how I learned enough to write these tips.
Hope this helps contuous use of this very helpful program.
Ron
Ronald A. Powell
CAD Developer/Operator
TGW Systems Inc.
Spring Lake, MI
Please mark Accept as Solution if your question is answered. Kudos gladly accepted. ⇘
