OOTB Multiple Visibility States - SOLUTION!

[Libbya]

I have done a fair amount of thinking on how to create multiple visibility states without using the broken vis-add-eng LISP and have come up with a workaround solution!  Obviously, doing all the itterations for multiple visbility states is a bit cumbersome, but at least there IS a workaround.  See attached.

[Libbya]

IIRC, any version 2007 or newer, including LT and verticals.

[Anonymous]

Now I have one new problem.

I have problem to prepare Dimension stile in the way to put the dimension to the center (horizontal and vertikal). Horizontal no problem but when I choose the "centered" commend for horizontal than the program throws the text higher instead to the center.

Before when I worked with AM_DIN dimension stiles I had no problem. Now I am preparing the "TEMPLATE" DWG neu and make neu stiles I have a problem.

Thanks for help.

Boris

[Libbya]

Your issue is not related to the topic of this thread.  Please start a new thread for your topic.  

[Anonymous]

Same issue how to activate visibility state wit the bridge can you explain why I followed and check the solution that you post still did not work well.

[jrr]

Do you have a reference block for a single interior elevation that would be similar to the multi-view that you shared.  By the way, that block is awesome and thank you for sharing.

[Libbya]

I'm not sure which block you are referring to and what block you are looking for.  

[marc.khalil]

I created a 'Bridge' Lookup parameter that links two lookup tables (right-click the lookup parameter tool on the palette and add two lookup actions to it).  On one of the lookup tables I placed all of the visibility states and on the other table I used the two move parameters as inputs and made all of their states correspond to all of the visibility states.

---

Thanks for the solution. I have one question: how did you ad two lookup table to the same Bridge parameter? I tried to follow your instructions here it but I am only allow one table per parameter. I'm using AutoCAD LT 2020.

[Libbya]

Go back and read message 16 in this thread.

[peterjwinberg]

In case it's helpful to anyone, I cheated my way to multiple VS's in this "selection table" by just scaling and moving the text I didn't want displayed.

The Lookup Bridge method would have required hundreds of VS combinations, so... no.

[Libbya]

I understood (and used) the scaling method prior to coming up with this method.  It certainly has it's uses and its downsides as does this method.  

[Libbya]

After looking at your block I would also mention that there is no need to use any visibility states or any scale actions for changes to text strings.  There are various ways to accomplish the same with far less effort than you went through.  Probably the easiest way would be to use three attributes with fields referencing your three lookups.  See screencast.

[peterjwinberg]

Welp, I guess my tumble down the rabbit hole wasn't necessary. Haha. However, my users prefer the hard method version because it doesn't have the gray background (and I don't want to turn it off because we have other fields that I want to stand out) and it doesn't require a regen 🙂

But still, thanks for the nudge to ease my pain in the future!

[Libbya]

REGEN is *not* required for the field to update.  Regen is only required if you want to immediately see the change.  The field updates based on the FIELDEVAL system variable which is by default (and IMO always should be) set to 31.  When set to 31 the field will update on open, save, plot, ETRANSMIT, and REGEN.  In other words, unless someone intentionally doesn't allow the field to update, it will update automatically before anyone other than the current user in the current session sees the value.  

[Libbya]

The gray field background also seems inconsequential to me.  It does not affect any plots and is only there as a visual queue to help prevent a user from inadvertently overwriting the field.  The overwriting of the field is the only real downside I see with that last version and even that can be largely prevented without issue in that block by placing the attributes onto a locked layer. 

Another option which is a fair amount more work is to use a block properties table to directly write the attribute values.  The selection process is via nested pulldowns, though, and I prefer the individual selections.  The block properties table is also a fair amount more work than the lookup version as you need to do the permutations of values.  However, you can copy/paste entire sections of the table (unlike lookup values) and so that speeds up the process considerably.  With the block properties table there is no field to overwrite (so there is no gray background) and the updated value is immediately displayed (no regen necessary). 

I'd personally opt for the lookup version, but the block properties version has its upsides also.  See screencast.    

[logan.lewis2B7ZD]

Hey, this is my first post on this site.  This thread, among others I found, have helped me immensely when learning how to effectively use Autocad. I'd like to thank all of you guys for your insights.

I have been working with Autocad for a while now, and I have a bit of experience with using multiple lookups.  Some of the blocks I've worked on have up to 256 visibility states. 

I do have an issue with a block I am currently working on, and I was hoping someone else here may be able to help.

I have been asked to make a block representing a wiring diagram that can have one of 4 different main options for it, and each option has a variety of sub-options.  The first one has 4 sub-options, the second has 8 sub-options, the third has 10 sub-options, and the 4th has 25 sub-options.  Because of how varied these are and there is text on them I need to use separate visibility states for each of these.  This is a total of 47 visibility states.   The point of this is to lock in the data in a specific way so that our checkers can look to see if this block is intact, and reduce the amount of time needed in checking.

I have been trying to find a way to make one dropdown for one of the 4 main options available, and then that opens up a secondary sub-option dropdown unique to each of the different main options which can be used to select the appropriate visibility state representing the selected option and sub-option.  Everything I know about using dropdowns tells me that this is 4x4x8x10x25 different permutations needed in my lookup table, or 32000 different rows in my lookup table that I need to setup.  I have been researching and have not seen anywhere how to do this in a simpler way.....  Does anyone have any ideas?  I would prefer to do it this way if it is practical.

[peterjwinberg]

You could probably do 4 visibility states - one for each main option - and within each VS have a lookup table for the various sub-options. The lookup tables would behave like an embedded VS. Depending on the objects, geometry, text, attributes?, other dynamic properties?, etc., it could possibly work. Need more info about the wiring diagram contents. Any files you can post/share?

[logan.lewis2B7ZD]

I haven't thought of doing something this way, this is an interesting idea, but I don't think it will work in this situation.  I'm limited in what I can share about what I'm doing, unfortunately, because of where I work and what I'm doing.  Based on the geometry of what I need to show, I do not think it would be possible to do it this way. 

I do have a test file setup just to test the lookups, and it kindof works, but it is very glitchy.  The only way I know how to do this without the glitches would be to use a single lookup bridge table instead of splitting it into 4 like this, but that's where I need 32000 lines in the table, which is not practical.

Let me know if you have any suggestions.

[Libbya]

Don't use the double lookup method for 32000 visibility states.  Someone else even made a lisp routine for making/defining the visibility states and the end result was that after you have input an absurd number of states, the block is extremely slow to work.  

When the number of visibility states becomes daunting then either use the scaling method for making things visible or a dot, or split it up into separate blocks.  

[Libbya]

Maybe I am misunderstanding your original post, but if you have 4 main options and then the sub options are all independent of the sub options in the other main options then there is only a need for 47 visibility states.  Switching is a bit complicated but certainly not 32000 rows!  Only one row per visibility state.  I'm uploading a long screencast now and will include it in a followup post.