Using Lookup Tables to Specify Visibility States

[Anonymous]

I know this has been addressed, I've been trying to understand forums explaining it but I am simply not getting it. 

Currently I am working on a weld dynamic block, I know that this has been done countless times but doing it for myself is for my own understanding.  I have attached where I am at in the drawing, with the block being 'Weld Symbol'.  If you open the drawing you can cycle through the visibility states which is pretty self explanatory to what I would like to accomplish.   I am attempting to get my lookup table to have me cycle through my visibility states to depict if:

A: The weld around symbol will be present.

B: What weld Symbol is used

C: If a opposite side weld symbol is used and if so which one.

😧 If there is a note attached.

I also do all my printouts 'annotatively' so I have attached annotative text attributes to the drawing which and be filled out by double clicking on the block or left blank.  Currently I do not have the following but intend on adding when I have my visibilities working correctly.

-A move point for each break in the arrow

-A flip action to flip the side of the arrow

-A scale feature to scale all but the attribute text so it comes out according to desired size

-Basepoint/insertion point

-Everything placed correctly.

I don't wish anyone to do all those as I'm just going to do them myself anyways to understand.  I just need help understanding how to use my lookup table to display my visibility I wish.

If you display the current lookup table in the drawing you can see the approach I have attempted, but I do not have the ability to change the grayed out "Read Only" text to allow reverse lookup so I can use it when inserted.

I hope this is clear.

Thanks for the help!

[Libbya · Accepted solution]

Right on.  Good work so far.  I also appreciate your attitude of wanting to learn rather than have it done for you.

I outline the procedure I've used for multiple visibility states in this thread:

http://forums.autodesk.com/t5/Dynamic-Blocks/OOTB-Multiple-Visibility-States-SOLUTION/td-p/4961288

The reason that the 'Read Only' is grayed out is because you cannot have the same name for an individual 'lookup property' on more than one row and still 'allow reverse lookup'.  You really want to set it kind of the reverse of how you currently have it.  You need a lookup table for each of the lookup parameters.  That table needs to link some dynamic action with each of the individual lookup properties for that table.  Then you need an invisible lookup parameter with two linked tables.  One of the two tables uses the dynamic properties of the other lookup parameters as inputs, the second table links them to the individual visibility states.  To link two table to one lookup parameter, right click the lookup parameter on the tool palette, click actions and then the little '...' browse symbol.  Then use ADD so that you place two lookup tables at the same time.  Set bactionbarmode to 0 so you can see them, then make the 'Lookup Properties" on the right match on the two tables.

[steven-g]

Nice way of doing it, it is heavy on the visibility states but still nicely worked out. Here's a trick I sometimes use in various forms, no need for visibility states just one linear parameter for each symbol, then use a scale action to make the symbol full size or scale it way down to .00001, a lookup table gives the various configurations. I sometimes combine this with wipeouts and/or moving things about with a point parameter. In the lookup table the values are .00001 and not just zero.

[Libbya]

Yes, I've used that method as well.  My OCD doesn't care for the remaining dots on the plan set - see the OFF state.  A reasonable solution is to simultaneously scale and move the remaining dot to on top of or behind other linework in the block, but that's a similar amount of work as the method I use for 'clean' multiple visibility states.

[steven-g]

Thats why I would tend to combine things with a move action, and then move and scale probably to the end of the arrow in a case like this, or slide them in and out behind a wipeout. I really like the method you use but as you say in the other post once you get to a few more combinations the number of visibility states could get to a very high number (and if you turn all the visibility states off the block vanishes).

[Libbya]

I agree, the number of vis states does get overwhelming fairly quickly.  You can avoid the option of the block disappearing, tho.  See the attached.  In that block, I used additional lookups that do not have the OFF option.  Those lookups become visible, taking the place of the 'normal' lookup, when the other two options are set to OFF.

[Anonymous]

Thank you both for taking the time to help me with this.  I know its been a while but other things came up and this had to be pushed to the side.  I was able to use your other forum Libbya and create the visibility states I desired. 

I have attached where I currently am with the symbol.  I have two things left in question.

One, how do I remove the custom option from the four look-up tables that I am using for my visibilities. 

The other is with the arrow head.  The arrowhead here is actually a leader with no text.  I did this so the arrow head would grow properly annotatively.  However after shifting the landing, and scaling the object when you change scales the leader breaks from the joint point.  I've been trying by switching move points to different parameters attempting to always make its base at the joint point but, being annotative it seems to move.  I was wondering if anyone would have any ideas, or if it would be better to draw the arrowhead and scale it with the drawing.

Thanks

[Libbya]

Congrats on getting as far as you have with this.  It is a complicated block that you are attempting.

As your blocks become more and more complicated it becomes ever more important to rename parameters and actions so that you can come back to the block in the future and edit it without needing to figure it all out again.  I like to set bactionbarmode to 0 and place all the actions in organized positions as well.  

I have found that the lookup input parameters do not need any actions associated with them.  E.g., you can ditch the move action associated with the Weld Move position parameter and it will work fine.  Similarly, the invisible circles can be removed.

If a basepoint parameter is present in a block, then the annotation scaling is done in reference to the basepoint.  In lieu of a basepoint parameter being present in the block the scaling is done relative the origin in the block.  My recommendation would be to ditch the leader.  Create a block that is the leader arrow and with the point of the arrow at the origin and make that block annotative.  Insert that block into your weld symbol block and associate the various dynamic properties to it.  That should solve your arrow issue.  

To get rid of the 'custom' option in the lookups, you need to make sure that the default positions of the input parameters correspond to the default visibility state of the block.  In other words, with a default visibility state of 'fillet', the x position of each of the input parameters should be 0.   See attached file.     

[Libbya]

Also, WRT the 'custom' option, it is also effective to change the 'Custom' Lookup Property so that the <unmatched> row has the same name as the default row.  In other words, where it says 'Custom' right above 'Allow Reverse Lookup' you can change it to 'Fillet'.  You would want to change it in both linked Lookup Tables.

[Anonymous]

Libbya,

Thank you for the help.  I have attached an updated drawing of the weld symbol.  Only thing I did not change was deleting the invisible circles and move actions associated.  I will do that later.  I was able to remove the custom and renamed all of the actions. 

Currently I am having trouble with the arrow block, I've yet to make an annotative block, but I believe I did everything correctly.  I changed the block to annotative, put the arrowhead on origin 0,0,0 along with a basepoint.  However whenever I insert the block the actual entity comes out far away from my cursor for insert point.  I do not know the reason for this, perhaps I created the block incorrectly. 

Also, should I make this entire block have the basepoint as the tip of the arrowhead and at the origin 0,0,0?

Thanks again!

[Anonymous]

I have updated the drawing some.

I removed invisible circles and move actions for the lookup tables.  I also created an annotative arrowhead.  However this still doesn't work as I was hoping because this arrowhead faces in one direction.  I did try creating an arrow but when I shifted the joint, the annotative arrow would not stretch the arrow base/line.  Only move.  If anyone has any suggestions how to complete the functionallity of this block it would be appreciated.  Thanks!

[Libbya]

A polar parameter with polar stretch will rotate the arrow with the changed angle.  See attached.

If you change annotation scales, adjust the arrow with the stretch angles and change the annotation scale again, then the arrow will not be associated with the correct point.  I do not know a workaround for that behavior as that is part of the annotative block behavior.  When you are moving an annotative object in one scale, it doesn't apply the action to the other scales..

[Anonymous]

Libbya,

Thanks again for all your help. 

I believe I have found a solution to the arrow and finalized the block.  I think!  It seems to work correctly now and I have attached it.

I made the attributes non-annotative size 1-16".  I made an arrowhead block that is non annotative and inserted it.  I then made the whole block annotative, with the basepoint at the arrowhead.  Now when the scale changes the text stays at 1-16" and grip points stay associated correctly. 

Couldn't have finished it with ya!

[Anonymous]

Hello everyone,

I have attempted to build my own block using Libbya's "bridge" method. I keep getting some odd results and I can't quite get it to work. I've looked to both Ryled's block and Libbya's blocks as examples on how to build my block. The attached file has the block that I have built shown 2 seperate ways. The first way attempts to use the "bridge" method. The second block is built using a block properties table to achieve similar results. I really enjoy using block properites tables because they are easy to build using excel. The downside to them is that this particular block has 5 different changing elements. So if the user decides they need one of those five pieces to change then they have to run all the way through the drop down menus. That is the upside of the bridge method in that if they want to change something they can turn it "on or off" instantly. If any of that doesn't make since just play with my second block to see what I'm talking about (both blocks are in this file). I've noticed that not many people use the block properties table for some reason. 

Thanks in advance!

[Anonymous]

I could be wrong but one thing I noticed right away is the number of visibility states vs. the number of lookup properties.

You have 5 different lookups, with 2 options a piece. (2*2*2*2*2 = 32) but you only have 16 visibility states.  Therefore your user will have to select the correct combination for it to appear and this could make the lookup table function incorrectly. 

With my block I still have to choose each option to make a change in my block however there was a possibility for each possible combination.  With your block there is not, so I would think that could be whats keeping you from achieving the desired operation you want. 

[Anonymous]

This will be the third time I try and respond, so I am sorry if three responses pop up later!

You have 5 lookup options (2*2*2*2*2) which comes to 32 different visibility states.  However you only have 16 visibility states.  I would suggest creating the other 16 options (Saved As a new file so I don't ruin your block) and see if the block functions correctly.  I had to do the same to get mine to work. 

I also want to note that I must make a selection for each lookup option for them all to apply.  This meaning that my block comes out with four options, to get option 3 to change I must also set option 1,2, and 4 even if they do not change.

[Libbya]

Your lookup table named EXTENSION was associated with the Lookup parameter TB Side and vice versa.  For your Cable Tag lookup, you have the input property for the Callout Move X instead of Cable Tag X.  You have 5 'visibility' paremeters with 2 options each so the total number of visibility states should be 2x2x2x2x2 or 32.  Your block as posted only has 16.  You have no visibility state to accommodate 

R-L-C-T, L-L-C-T, R-E-C-T, L-E-C-T, R-L-C, L-L-C, R-L-T, L-L-T, etc... and yet those situations occur.  If you add those visibility states and correct the Bridge tables to accommodate them your block works fine although, I'd also change the lookup parameter locations when the Left location is selected.  In the attache file I did a few of the missing visibility states and some of the corrections to the tables so that it shows as partially working.

Yes, block properties tables are easier to setup, but the end result totally stinks in comparison.  

[Libbya]

I would also add that if you want to eliminate potential options (such as all OFF so the block doesn't disappear entirely) then you can add a contextual lookup parameter and table that does not have the undesired option or hide the lookup tables for visibility states where you don't want the ON/OFF option to appear.  For example, hide the Tag lookup when the extension, line and callout are all set to OFF.  The attached block has some of that functionality added.

[Anonymous]

Thanks for taking a look at this block for me. I am working on getting the other visibility states added to it and I've fixed the tables (I think). I will take your advice on turning the tags off for certain visibility states so that the block doesn't dissapear. 

Just out of curiosity, did you look at that second block in my original post? Just curious what peoples thoughts are between using the 2 blocks. Basically once I get this block using the "bridge" method complete, I will allow the other users here to test them out. Then we wll make a decision on which type of block to use... the bridge type with multiple states or the block that uses the block properties table. 

Once I get this cable tag (bridge) block completed and all of the bells and whistles added I will attach it for you guys to see.

Thanks again for the input!

[Libbya]

I had one other thought for you to consider.  If it were my block and considering each of the visibility states are ON/OFF (two states), instead of using individual lookup tables to choose the ON/OFF states, I would add Flip parameters for the individual inputs.  That way a user does not even need to open the pulldown.  Attached I removed the lookups for side, line and extension and replaced them with Flip parameters and actions.  For a Flip grip to be visibile it needs to have an action attached that actually flips something.  The object flipped can be invisible for all states or a line on the flip line so it doesn't actually move.  

I would certainly prefer the lookups over the block properties.  The ability to switch just one item without taking the time to wade through the block properties table options would be greatly appreciated.  If the lookups were replaced with flip grips the time saved in switching would be even more significant.  No contest...