View Full Version : Troubles w/ subst and att visibility. .
M. Kubitza
2009-12-21, 03:10 PM
What I am wanting to do is have attribute visibility set to on/invisible or off/visible based on the value. The end result would be to have this in a reactor which will change the code no doubt, but for now I am having issues figuring out how to get subst to work, I keep getting nil result. Actually trying to run the routine locks up acad so I assume its looping. Only one block is present in the dwg for testing.
Here's the mess I quickly threw together friday afternoon which didn't shock me when it failed, but even after toying w/ it over the weekend I came up with nothing unfortunately. This code doesn't go as far as changing the property based on the attribute value, this was just to see if I could get the property to change manually first. .
(defun C:attvis (/ eset blkCntr en enlist blkName) group70
;;;--- If that type of entity exist in drawing
(setq eset(ssget "X" (list (cons 0 "INSERT"))))
;;;--- Set up some counters
(setq blkCntr 0 cntr 0)
;;;--- Loop through each entity
(while (< blkCntr (sslength eset)))
;;;--- Get the entity's name
(setq en(ssname eset blkCntr))
;;;--- Get the DXF group codes of the entity
(setq enlist(entget en))
;;;--- Get the name of the block
(setq blkName(cdr(assoc 2 enlist)))
;;;--- Get the entity name
(setq en(entnext en))
;;;--- Get the entity dxf group codes
(setq group70(cdr(assoc 70 enlist)))
;;;--- If group70 is set to 0 (off / visible)
(if (= group70 0)
;;;--- Set group70 to 1 (on / invisible)
(setq en (subst '(70 1) (assoc 70 en) en))
)
;;;--- Else, set group70 to 0 (off / visible)
(setq en (subst '(70 0) (assoc 70 en) en))
(entupd en)
(princ)
)
M. Kubitza
2009-12-21, 05:23 PM
Got it! Now just have to redo it all to make it work as a reactor, yay.
irneb
2009-12-22, 11:35 AM
Say, have you tried using Visibility states inside the BEDIT command?
You don't mention which version of AC, but this should be available from 2006 onwards.
M. Kubitza
2009-12-22, 04:58 PM
Say, have you tried using Visibility states inside the BEDIT command?
You don't mention which version of AC, but this should be available from 2006 onwards.
I am using 2010LT at the moment with addon package for lisp functionality, pressuring the boss to step over to full version.
I use visibility a lot, but I need the attribute to appear and disappear according the its value, if you can somehow do that with visibility its news to me. My block currently has two attributes, one for all the values that I want to see and one for the value that doesn't need to be seen, but I am tired of dealing with two different attributes and it causes problems/confusion if you copy&paste the block and forget to delete the invisible value etc.
irneb
2009-12-22, 07:07 PM
If you set the AttDef's properties to Lock position=Yes inside the block, the DB Visibility state should work on that attribute. If it's not locked, then DB actions / visibilities don't affect the attributes.
Be warned though. You can still set its own invisible property to true / false ... but the attrib's invisible=yes would override the visibility=on, and visa versa the visibility=off would override the invisible=no.
Also, the attribute is still going to be there if you've got invisible=yes. it's just going to be hidden. If you use the DB visibility the attribute won't show in the dialog or properties palette.
irneb
2009-12-22, 07:15 PM
Now if you want to perform the turning on / off of the visibility state, I think the only solution would be to use a lisp reactor. In which case it does seem as if VisStates are not the thing for you, since the hidden attrib would still need to have a value which governs its visibility.
You may have to use 2 reactors: one for testing if the block is inserted, another for testing if the value's been modified. Then you need to install the LSP on all PC's which are going to work with these blocks.
And in this case I'd advise turning each affected AttDef's Lock position to No inside BEdit. Then run AttSync ... oh sorry you've got LT, I think AttSync (or BAttMan) is only available to full AC.
irneb
2009-12-22, 07:21 PM
I am using 2010LT at the moment with addon package for lisp functionality, pressuring the boss to step over to full version.If it's a question of cost, then you could look into BricsCad which is a clone of Full AC 2005 - using 2009 DWG files as native. It's features are comparable to 2005 (including Lisp and many others not in LT - not DB's yet), but its price is a smidgen below LT's.
I'd not advise it if your current DWG's are using any of the "new" features of AC, e.g. DynBlocks, Tables, Data Extraction, etc. These are not implemented as yet, except with addons which aren't as good as AC's built-in commands. They do state they're working on it though :roll:
M. Kubitza
2009-12-22, 08:10 PM
Yes all of our dwgs use dynamic blocks annotation etc.
As for the block, the attribute can't be locked as it has to be able to move as there is always something in the way to work around. I only want a reactor because I want the visibility to set itself based on the value input by the user, and if no input have a default "##" show up.
Just working on automating as many of our mind-numbing tasks as possible as I get the time. Thanks for input! :)
irneb
2009-12-22, 08:38 PM
OK, could you attach a sample DWG with the block and a description of when the invisible gets changed (i.e. at which value(s) does it become hidden and visa-versa).
M. Kubitza
2009-12-22, 08:49 PM
The value 15 should always be invisible. The rest always visible, and if no input by user on insertion have value default to "##" and always be visible. I wrote routine that will do if you click on block after running just to experiment with subst., now just have to turn around and put into reactor.
There is more to it than just this however, I will have to do a check on the block name, none of our other blocks currently use a value of just 15, but may in the future so need to address that issue now. Also will need to check the attribute tag as we are currently updating block library so multiple attributes are being added to some blocks, and some fields in attributes etc.
As our blocks are dynamic, I read about vla-get-effective name will return the actual name of the block rather than the "*U###" that shows up once you mess with the block, is that true? That is the way I understood it when I read it. If that's not true then we'll have a problem.
Just an idea, something I should try:
1. - In the icon for editing attributes I should include the new lisp function, to be executed automatically after.
2. - I should design the block with key-letters for the attributes I want to control the visibility and backup attributes. The backup attributes should be always visible. I also should include attributes or key-values. Main attributes and key-values attributes should be invisible. So, I can see only the backup attributes. Backup attributes should not appear in the dialog box.
3. - The function reads the blocks, looking for the attributes with the key letter.
4.-Then, I read the key value marked for that attribute (that information should be in the key-value attribute). If true, I put the value of that attribute in the backup attribute of the main attribute; if not, I erase the value of the backup attribute.
5.- Graphical appearance should be ok, and main attributes have always the real valor.
Powered by vBulletin® Version 4.2.5 Copyright © 2025 vBulletin Solutions Inc. All rights reserved.