Using Lookup Tables to Specify Visibility States

[ryled]

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]

Here it is one more time.  I believe it is all complete.  All of the necessary visibility states are present and everything seems to work as it should with flip grips instead of lookups.  There are only 30 visibility states because the states of R and L with none of the lineowork are not necessary.

[Libbya]

Ryled, I was looking at your finished block and wanted to mention that it might work better if you set the initial positions of the input point parameters so that their initial X value is 0.  That will then correspond to the initial visibility state and the visibility parameters will work right off the bat.  You also may still have a couple issues with the 'opp weld' lookup and 'Note' lookup or else you may want to hide them for some of the weld visibilities if you don't want those options to exist.  Attached is the block with the input positions moved.

[DisposedHero]

Wow, I didn't expect you to complete it for me. Thanks! I was nearly complete with finishing it using the flips as you had suggested. That is a very clever idea that I haven't seen employed on a block before. Thanks for your input! I'm going to continue adding some of the other items to this block that need added to make it complete. One of the things I need to do is make the line, callout, and tag able to stretch to the right. The reason being that when the user fills out the attribute "extension" the text can be long. So I will add a stretch action so that everything to the right of the extension attribute can be moved.

One more question: is it possible to control the value of an Attribute with a lookup table? I know it's possible with a properties table. But basically, the callout represents a cable size, and we have a list of them that we use. I'm afraid the only way to control it would be just put text in there and control it with visibility states. If that's the case then I'll leave it out for now and just make the users type in the cable size. It would add significantly to the amount of visibility states.

Thanks again for your time on this block!

[ryled]

Libbya,

I am a bit confused as to what you are meaning here.  Are you recommending that all that parameters be moved close to the origin?  Also I noticed the basepoint was also moved.  I tested the block and it seems to behave the same as before if you could point out what I'm missing?

Thank you

[Libbya]

Yes, you can control the value of an attribute using a lookup.  There may be a simpler way, but a way I have used before is to place a point with grips set to zero and then use either the x or the y value of the point as the input value for the lookup.  You can then use a block placeholder field in your attribute so that it references the same x or y value.  It does require a regen for the field to update.  See the attached file.

[Libbya]

Ryled, what I was saying is that within the block, you should adjust the base location of your input parameters so that they correspond to the values listed in the Bridge lookup table for the current visibility state within the block itself.  That way, when inserted, your lookups should work fram the start.  If 'Fillet' is the current visibility state in the block and the x values of all of the input parameters are 0 when the 'Fillet' state is active, then you should move all of the parameters so that their base location is 0.  

[ryled]

Okay, I get what you are saying now.  Is this a proper form of 'block management' because after doing so the block still functions the same, at least as far as I can tell.

[Libbya]

No it's not just a form of proper block management, it is also functional.  There is a bit of a discrepancy in your block because the base point is not at the origin within the block.  I forgot that when I moved your input parameters.  Here is your block again with the base point at 0,0,0 and the input parameters with x=0.  With it set up that way, the lookups should immediately work when the block is inserted.  If you want the base point and insertion point at the arrow AND your lookups to work when you first insert the block, you will need to move the linework so that the arrow point is also at 0,0,0 and adjust your dynamic parameters/actions accordingly (e.g. stretch windows and flip lines).  As a 'form of proper block management' I always start my linework/parameters so that the basepoint is at 0,0 to avoid later issues such as these.    

[DisposedHero]

Thanks for that example! I have now incorporated two extra tables into my block, one for cable sizes and one for wire color. I have another question, what do I need to do so that the user never see's the options that aren't neccessary. Basically when the extension is turned off I don't need the line, callout and tag to be showing. But if I delete their respective visibility states the block won't work. Is it as easy as just keeping the visilitity state but turning the various items off? I have played around with the visilbility states but to mixed results.

As far as the right side of the block goes I have pinpointed these visiblity states as ones that our users have no need for:

RLCT

RECT

RET

RLC

RL

REC

Basically if the extension is off we don't need a line. If the extension is on but the line is off, we don't need the callout and tag, etc... I'm not sure if any of that makes sense.

I will attach what I have so far that shows the two extra lookups for wire color and cable size. Thanks again!

[Libbya]

You can delete those extra visibility states and the block will still work but will seem broken as the user can still select the state but nothing happens visually.  The easy solution is the eliminate the user option of those states by hiding the flip parameters that would access that state.  You can see that I did that for the R state and the L state (the two states where all linework would be turned off.  I did so by hiding the flip for the the last visible item in each of the visibility states with just one item.  I hid the E flip in the RE state, I hid the L flip in the RL state, I hid the C in the RC state and hid the T flip in the RT state.  To make it so that the RLCT option is not accessible and the corresponding visibility state can be deleted, hide the E flip in the RELCT state, hide the L flip in the RCT state, hide the C flip in the RLT state and hide the T flip in the RLC state.  Then the RLCT state is no longer user accessible and can be deleted.  It's a bit of work to fine tune but is not hard once you get the hang of it.

BTW, great work on the block so far.  

[DisposedHero]

Interesting. It may take me awhile to wrap my head around this. Right now i'm kind of confused going into it. How did you approach solving the RLCT option? I did just as you had suggested and it works but I'm trying to figure out how you came to those conclusions regarding which flip to hide and on which visibility state.

Thanks for the comment on the block too, I'm pleased with the direction it's headed!

[Libbya]

Any given visibility state is accessed when a last flip parameter turns the last 'extra' item off or turns the last 'lacking' item on.  Therefore you can eliminate access to the state by turning off the flip parameter for the last 'extra' or 'lacking' item.  So, for another example, I'll use the REC state.  The states with one extra item are the RELC and the RECT states.  The states that are lacking one item are the RE state (lacking C) and the RC state (lacking E).  You can ignore the R as I assume you will be eliminating the states in pairs.  There will eventually be no L version of the state so there will not be any LEC to flip to REC. 

[DisposedHero]

Ok I have rebuilt this CABLE TAG block now and have it working almost 100%. I renamed the visibility states to make more sense and I added all of the stretch and move actions to it as well. I would say this is probably most most complicated block I have made. I have not yet gone through each state to get rid of the various flip states as we had talked about in the last 2 messages. It seems to be very tedious and honestly I still couldn't figure it out exactly. 

This leaves me with one more (complicated) problem which you will see when you open it. The attributes that show on the left of the block need to be able to move with the actions that happen on the right side of the block. I have toyed with doing some chained actions but I haven't jumped fully into that part of it yet. Anyway, take a look and let me know what you think! Thanks again to Libbya and Ryled for your help on this.

[Libbya]

Before getting into the stretch/flip issue, I wanted to mention that you could automatically set up a line stretch for the specific lookup options that have a longer text string.  You could set up linear stretch actions with no grips showing that move the various items a specific amount for the specific selection.  Just a thought...   

WRT the flip/stretch issue, is there a reason for the two sets (left and right) of attributes and linework?  Can you use just one set and flip it for the left version?  Option 1 in the attached file shows that behavior.

If you want to keep the two versions you could try chaining your existing parameters and making ones that are mirrored on the other side that are moved at the same time, but you have several stretch actions with windows over the same linework and getting it all to work properly (avoiding unwanted chain reactions) may be difficult.  

Option 2 would be to change each of your linear parameters so that the base location is midpoint, add a second stretch going the other direction and change the number of grips to 2.  That approach would work, but it will always show both grips and the grips on the other side of the block showing up would bug me.  That option is easy, tho.    

The approach I would take is Option 3, and is a little alternative in its thinking.  In the block I have two mirrored sets of linework and at that linework is a single linear distance parameter (Master) and a flip.  The stretch action of the Master does not act directly on any of the linework but instead acts on the end point (lower) of a second chained linear parameter (Slave).  The stretch action has an angle offset of 270° so that when the Master is moved to the right, the Slave is moved down.  The Slave parameter has two actions attached to it.  One moves the right side with an angle offset of 90° and the other moves the left with an angle offset of 270°.  The flip action flips ONLY the Master parameter and the two Slave stretch actions.  The result is that when the flip is activated the Master parameter flips to the other side and stretch angles flip so it all works correctly.  The benefit to this approach is that the Slave parameter can be placed anywhere in the block (avoiding unwanted chain reactions) and as long as the stretch window is around its endpoint and the parameter is oriented the same direction it will work as it should.  

[DisposedHero]

Thanks so much for all of the feedback! I hadn't thought of changing the stretch in conjunction with which lookup option is selected. That's a good idea that I will be looking into. As far as the reason for having a right and left option. When the attributes on the right are mirrored to the left their orientation doesn't change so when filling them out they type over the top of my linework. I realize that I could use multiline attributes that would not behave that way. However I hate that when you go to edit a multiline attribute it adds an extra step of having to click the ellipsis "...". I know you can hold CTRL down while you double click a multiline attribute to get around having to use the ellipsis but it's still an extra step.

Thanks for providing those other 3 options for the stretches. I will be taking a look at them this morning and I'll see how I may apply them to this block. I really like option 2 for it's simplicity. I wish that we could hide the individual stretch icons, that would make this even better.

One final question: my block contains those two lookup driven attributes (wire color & wire size). If a user isn't paying close attention it's possible for them to overwrite the lookup selection in the attribute editor window. When that happens it blows the field up. Is there a way to prevent this? The only way I can figure is to put another lookup table there that has 2 options. Maybe 1 is "user input" the other is "list options". If user input is selected it turns off the attribute that gets data from the lookup and just puts a "new" blank attribute there. If "list options" is selected it turns off the "new" blank attribute and turns on the original one that gets data from lookup.

[Libbya]

I don't know of any way to prevent other users from destroying fields other than the judicious use of pain...

If you need to allow user input on those two attributes, I would recommend doing similar to what you describe.  I can think of two options.  One is less likely to be screwed up by a user (still not impossible, though) but is considerably more work to set up.  The other is easier to set up but much more likely to be messed up by a user.

For the option that is harder to set up but also less likely to be screwed up, here it is...  There is no need for another lookup.  I would place a 'User Input' option at the top of the Wire Size lookup and have that choice drive another visibility state that turns off the field attribute and turns on the blank one.  You would need an additional visibility state for each of the states that displays either of those two attributes... 30 more...  🙂

The other option that is more challenging to the user is to have one of the lookup options be just a space.  Then add another attribute in the same location with a default value that is empty.  When the user wants to add user specific text they need to select the blank option in the lookup (so the lookup text disappears) and then right-click the block and select 'edit attributes' and scroll down to the blank user input attribute and enter their text.  

The attached file has both options.

[DisposedHero]

Ok I went ahead with the more difficult option and added the neccessary visibility states. I'm not quite sure why it isn't working though. The cable size lookup allows me to change from "user input" to an item from the list. However, when I go back to use an item from the list it doesn't update the field. The attribute for the wire color is working great however. 

[Libbya]

The only issue I saw with flipping to the 'User input' for the wire color or wire size was being caused by the fact that you had the input parameter point base location with a value of x=1/4".  I moved both input parameters to 1,1 and now the lookups work right off the bat.

[DisposedHero]

Ok I have now added the stretch actions to this block. They almost work! I can't quite figure out what is going on though. It seems like as I stretch one action it moves the handle of another one. Also, after I flip it once it works great on the left. But after it has been flipped to the left it does some odd things if you try to stretch it. 

I have tried a few other approaches as well. One of which involved converting all of the attributes to multiline atttributes with a value that held a field. The field would look at a "master" set of attributes to gets it's value. This way the user would fill out the attributes and then the right and left attributes that are in this block would fill out accordingly. It kind of works but it seems pretty touchy and a bit unreliable. I will include both blocks in this post.

[Libbya]

The issue that is causing the grips to move twice as far as the stretch is caused by the fact that you included the parameter that is driving the action in the stretch that is attached to the chained parameter.  Because of this, the grip is moved the correct amount by the user, but then because the driving parameter is part of the selection set of the chained stretch, that grip movement then causes the chained stretch to move the main parameter the same amount again.  You must include the other moved parameters in the selection set of the chained stretch but not the governing parameter.  

The reason the objects move the wrong direction when the flip is activated is because you have some things in the selection sets of the wrong actions.  You need to include the chained stretch actions in the selection set of the flip action.  When the chained stretch actions are flipped, the angle offset changes from 270° to 90° and vice versa and so it will reverse the direction of the stretch action when the flip is activated.  The way the block is currently set up, you are flipping the linework, but not the attributes, it's fine to do it that way, but you then need to sort out what objects are included in which action's selection set.  If you are flipping the linework, then you need to include the linework in the selection set of the *governing* parameter that is flipped with the linework.  In other words, if flipping the linework, you need to add a second stretch action to each of the governing parameters and cause them to stretch the linework.  You then need to make sure the linework is not included in the selection set of the chained stretch.  You need to include the attributes in the chained stretch's selection set and not in the governing parameter's selection set.  Another option would be to remove all the linework from the flip action, turn off the visibility of the right linework and turn on the visibility of the left linework when the flip is activated.  If you change linework with the visibility, then you will not need the added stretch actions on the governing parameters and instead include both linework and attributes in the appropriate chained stretch actions.

Hopefully that all makes sense.  If not, then let me know and I'll explain further.