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]

I would mention one other option that occurs to me.  Because you already have two sets of attributes and two sets of linework in the block, instead of using the chained parameters it may be psychologically simpler to add a second set of parameters to the left side.  Then each parameter on each side of the block would need two stretch actions attached to it.  One stretch would move the right side and one stretch would move the left in the opposite direction (angle offset of 180 instead of 0 and vice versa).  Then visibility would change which set of parameters showed up.  Then the center flip would not flip any of the linework, parameters or attributes, it would just signal the lookup to change visibility states.

[Libbya]

See Opt. 4 within the attached file.  

[Anonymous]

Yep this is the same idea that I had in mind yesterday but I was missing the dual stretch portion of it. I was trying to chain the left side to the right side with a distance multiplier of -1. It didn't work. Thanks for the idea of doing it this way! Only 1 problem... how do we handle the flip "inputs" that control the visibility states since we are no longer flipping anything from right to left and vice versa?

[Libbya]

Just flip something that is invisible in all states and the flip grip will be visible.  The Side flip is already being used by the Bridge lookup input properties and the appropriate visibility states already exist.

I took a quick look at your attributes in the other file.  You might have to make a dynamic action to get them going initially and then a regen with any changes but they seem to work fine.  Was there an issue with them?

[Anonymous]

Ok I have now updated this block again. I have added new inputs for the leftside of the block as well as 2 new lookup tables for the wire color and wire size on the left side of the block. The stretches and flip are working perfectly however, now the inputs aren't working. None of the parts are turning on or off as they should. I'm sure it has something to do with my bridge tables. I'm getting close to my wits end on this thing! Thanks for sticking with me on it. Would you mind taking a look?

Thanks!

[Libbya]

Don't give up now.  You are very close to having it all working.  I'll take a look.

[Libbya]

The main issue is that you had added the L flips into the Bridge input table and so, for a given visibility state, both flips (L and R) would have to be either ON or OFF.  If one was ON and the other OFF, then it would result in a condition that didn't coincide with one of the lookup properties and it would go to 'custom'.  I added 4 more simple double lookups for the 4 flips so that when an R one flips, the L one flips at the same time and vice versa.  I then removed the L inputs from the Bridge input table as at that point they were just redundant.  

Stretch13 had a distance multiplier of 180 instead of an angle offset of 180.

The input point parameters for Wire Color and Wire Size were placed on 0,0 which corresponds to 'User Input' and yet the initial top (default) visibility state was not for USER INPUT for either lookup, so the bridge would not work initially anyway.  I moved those two point parameters to 1,0 so that the x value is initially 1 which corresponds to BK on color, etc.

There is not a visibility state for R-ECT B-UI, R-ET-BUI, etc...  but they are accessible.  I'm not sure if those additional states are needed or if you should hide the flips that get to them.  I created a new visibility state called CUSTOM.  Whenever the Bridge conditions are unmatched, it will flip to that state, all linework and attributes will disappear and the work "custom" will appear on your screen in large letters.  You then need to either hide, in the previous visibility stat, the flip that you just flipped or add the visibility state that should be present and add those conditions to the bridge.

Instead of the two separate L and R lookup tables for wire color and for wire size, I used 'add properties' > 'add lookup properties' on the R table in order to add the L lookup parameter to each.  It probably wouldn't hurt anything to have each as I believe both tables were allowed reverse lookup and would have switch the other one when the input parameter changed, but I was trying to track down why the fields sometimes stopped responding.  I found that the L and R fields were both directed to the R lookup.  That should work fine, but it wasn't, so I changed it so that the L fields were directed to the L lookup and lo and behold the fields work consistently.  I'll have to remember that one.  It must have something to do with the combo of field and visibility states.

There seems to be some other bits of minor cleanup that will require you to go through some thorough testing and correcting small details like making sure the correct items are displayed and move, etc.

The flips that flips the fillet next to the flip that turns on/off the fillet is a little confusing.  Maybe place a defpoints box or X on one of them and have it move with it just to differentiate.   

It's almost there.

[Libbya]

The method I just outlined in this thread will prevent users from destroying your fields and yet give them the ability to edit the appropriate attributes for user input. 

[Libbya]

Here is the block with the attributes updated so they are referencing the User Parameters.

If the text length changes, the justification will be off.  You can run the JA command found in the LISP to correct the justification (and regen any fields that have changed).

(defun c:justifyattributes ( / )
  (command "-layer" "m" "Attlock" "unlock" "Attlock" "")
	(command "regen")
  (command "-layer" "lock" "Attlock" "")
  (princ)
  )


(defun c:ja ( / )
  (command "-layer" "m" "Attlock" "unlock" "Attlock" "")
	(command "regen")
  (command "-layer" "lock" "Attlock" "")
  (princ)
  )

  (command "-layer" "m" "Attlock" "unlock" "Attlock" "")
	(command "regen")
  (command "-layer" "lock" "Attlock" "")

[Anonymous]

Wow, thanks for taking the time to go through and update all of those things. I'm in the process now of adding the various visibility states that are leading to a "custom" setting showing up. Thats a really good idea to make the custom visibility state, it makes it much easier to trace out. You have saved me again! thanks. 

[Anonymous]

I have been on cad for 10+ years and am interested in learning more. the thing im having the hardest time grasping is how do you link the Visibility States to excel?
i have a dyn block with 10 Visibility States that i want to link to an excel doc

[Anonymous]

Ok, my brain is officially fried on this block. I have added every possible visibility state that I can think of. If you try changing the wire color from "BK" to "user input", it doesn't readily change. If the color and wire size are both set to "user input" the visibility state should be "R-EFCT B-UI" but I can't get it to change to that. Very odd!

[Libbya]

R-EFCT B-UI and R-EFC B-UI both seemed to fail.  I went into the two Bridge lookup tables and erased and re-typed those two names in each of the tables.  I didn't see anything wrong with the two names in either table, but they didn't seem to be linking properly.  Anyway, since doing that, I could not get the block to misbehave.

[Anonymous]

Thanks Libbya! I went ahead and re-typed those visibility states as well and it worked. That was an odd thing. I think that block is fully functional now, thanks again for your help on it! 

I have a new block that I'm working on that deals with sort of the same set of circumstances as far as the multiple lookup tables and visibility states goes. I'm not sure if I should post it here or start a new thread?

[Libbya]

Glad to hear you got it all working.  That is an impressively complicated block.   

I'd probably start a new thread for your next one.

[Ebbe_T_Hansen]

Hope this is the right place to poste a question, as I know that this subject has beeen discussed many times since the last post in this thread.

For me the missing link is how to associate two lookup tables to one parameter. If you try to do it "the usual way", you will get the message "Lookup parameter already associated with a lookup table." And if I "right click the lookup parameter on the tool palette" I see no way to follow the instructions. Just to clearify how I understood this, there is a screenshot attached, to show what I did.

/Ebbe T. Hansen

[ojuris]

You not try in right place

Choose Parameters Sets tab and right click Lookup Set icon

[Ebbe_T_Hansen]

This makes no difference to me. The right click menu is exactly the same

[Libbya]

Your scree capture shows the right-click of a lookup action.  You need to right-click a lookup parameter instead.  On the right-click menu of the lookup parameter, select 'Properties'.   See the 'Lookup Parameter RC' jpg below to see what the lookup parameter right-click menu should look like.

When you have selected 'Properties' from the lookup parameter the tool properties window will pop up.  See the 'Lookup Properties' jpg below to see what the lookup properties window should look like.  

You can also see in the picture what it should look like when you click on Actions.  The three little 'browse' dots will appear at the right of the field (the cursor is on them in the jpg).  Click on those and it will take you to the Add Actions window.  See the 'Lookup ADD' jpg to see what the Add Actions window should look like.  

The cursor in the picture in on the Add button.  Click it and a second lookup action will appear on the action object list.  

Click OK and you will be back on the tool properties window where now the Actions field should say 'Lookup, Lookup'.  OK again and you will be back to the parameters tab of the authoring palette.  Select the lookup tool and place the lookup parameter in the block.  

You will need to have the system variable BACTIONBARMODE set to 0 instead of 1 in order to see the two lookup actions.  

Double-click on of them to open the table.

[Ebbe_T_Hansen]

Thanks a lot. This is so clear that even I get the full picture.

/Ebbe