Featurescript Lookup Table in UI

Hugh_Goodbody

I have a lookup table in a UI, I would like to poplulate the following UI field with data selected from the first field.

For example, user selects Pin diameter = 20mm, in the data table (I have this done), there are two entries for 20mm with two different OD options (35mm, 40mm), I would now like the next field in the UI to only display those two entries from the table - is this possible?

NeilCooke

Yes, you can just nest another "entries" below the "20" entry. See the Beams feature for examples.

Hugh_Goodbody

Thanks Neil, so obvious!

I have most of my information in excel, are there any utilities you know of which are available to help create these nested dictionaries?

NeilCooke

Hugh_Goodbody said:

Thanks Neil, so obvious!

I have most of my information in excel, are there any utilities you know of which are available to help create these nested dictionaries?

I bet somebody has created one, but I've always done them by hand by concatenating cells in excel - painful.

Hugh_Goodbody

Next question, I have the lookup table sorted in the UI. I do not need the Flange OD field to show as this value is calculated from the bore entered by the user in a previous field. All I need the user to choose is the number of holes and the PCD for the relevant Flange OD, the output would be the "Code" value.

Is this possible?

if (definition.fixingEnum == tubeFixing.FLANGE)<br>            {          <br>                <br>                            <br>                annotation { "Name" : "Flange", "Lookup Table" : flangeTable}<br>                definition.flangeBore is LookupTablePath;<br>                <br><br>                annotation { "Name" : "Flange Front CC" }<br>                isLength(definition.flangeClosedCentres, LENGTH_BOUNDS);<br>            }

kevin_o_toole_1

@Hugh_Goodbody
Just to clarify, sounds like you're saying there are cases where you don't want OD to show. Are there cases where you do want it to show?

One possibility is changing "OD" from being part of the lookup table to being its own enum dropdown. That would allow it to show conditionally based on previous parameters, or could allow future parameters to show conditionally based on it (including showing different lookup tables). Though I'm not sure if this solves your problem, or if I fully understand yet.

Hugh_Goodbody

@kevin_o_toole_1

I don't want OD to show at all, I just want the user to be able to choose Number of holes and PCD which are available for the OD entry in the table. The OD is calculated elsewhere and I dont want it as an option to change.

For example in the case above, the 80mm OD has been worked out previously, I now wnat the user to be able to select either a 4 hole of 6 hole flange with PCD which is only available to the 80mm entry in the table. Does that make sense?

Alex_Kempen

@Hugh_Goodbody, I think what you're trying to accomplish is technically possible, but I'm not sure if it's feasible for you. @kevin_o_toole_1's suggestion to break your lookup table into smaller sections is a good one; however, it probably isn't possible to "calculate an OD" and then show/hide the appropriate sub table without using editing logic, which can be quite tricky to learn and use. Even with that, I can't guarantee that the solution you end up with will make you fully happy unless you're willing to jump through a lot of hoops to get it to work. If this is your first FeatureScript, then it probably isn't worth the effort.

If you explain what you're doing in more detail, including how you want to calculate your OD, myself and others may be able to give you a better idea of how you can proceed.

Hugh_Goodbody

Alex_Kempen, I had contemplated breaking the lookup tables into smaller sub tables, I would also need to do this for two other lookup tables, so would end up with a huge amount of sub tables, which is why I am trying to find another solution! I have also come to the conclusion that editing logic might be the answer, but I am not quite sure how to implement it with the lookup table! I currently have an editing logic function just printing out a line when the user edits the bore parameter. - a small start!

The OD is calculated from simple math from the user entered Bore (eg OD = Bore + 10mm)

I have written a couple of featurescripts, but am still a complete amateur at this, I would however like to learn how to do this for future featurescripts.

Alex_Kempen

@Hugh_Goodbody, I think there's two ways you can do this, both involving editing logic. The first is to use editing logic to set one or more options in the lookup table. Usage wise, this is a bit janky, since the user will still be able to change the lookup table as they see fit, even if the first option is automatically selected; the only way to truly prevent this would be to automatically change it back if the user tries to change it, but that seems like it could be really confusing, and I want to strongly warn you against doing something like this since it can be really frustrating if a user can't figure out why they can't edit something they think they should be able to change.

The second way you can do it is using what I like to call the boomerang technique. It's a relatively new idea I came up with a month or so ago. The basic idea is to use a combination of hidden parameters and editing logic to control the visibility of one or more parameters in your annotation. In your case, this would probably work by creating a hidden Bore enum at the top of your precondition, then using that enum to drive the visibility of the corresponding look up tables. You would then need to select the appropriate enum option inside the editing logic based on whatever logic you want. You can see an advanced example of this in the Updated Spur Gear FeatureScript I posted yesterday; I can also provide simpler examples if you're struggling to understand what's going on. This would be by far the most user friendly solution, but I can understand why you might be hesitant to go down this path. Ultimately, the choice is up to you.

Hugh_Goodbody

@Alex_Kempen, Thanks for your insight. I think the second option is the best one. I have had a play around but run into an issue you might be able to guide me through. I have created the enums and the editing logic and the seperate lookup tables.

I have an error in having a duplicate feature parameter, how do I get around this?

Alex_Kempen

@Hugh_Goodbody, here's some recommendations on your code so far.

// In FeatureScript preconditions, you aren't allowed to create one or more parameters with the same definition key (e.g. definition.flangeBore)
// Note that this is separate from the user visible name defined under "Name", which can be duplicate across multiple parameters
// Thus, I would recommend changing your code to look something like the following:
if (definition.boreSize == BoreSize.BORE35 ) // enum table names generally have the first word capitalized, too
{
annotation { "Name" : "Flange", "LookupTable" : flangeTable35 }
definition.flangeBore35 is LookupTablePath;
}
else if (definition.boreSize == BoreSize.BORE45 ) // note the use of else if
{
annotation { "Name" : "Flange", "LookupTable" : flangeTable45 }
definition.flangeBore45 is LookupTablePath;<br>}

// In order to use these inputs in the Feature Body later on, you can use an else if structure to collect from the appropriate table
// based on your hidden enum. See the Variable Feature in the STD library for a good example of this structure.

// Also, note that in order to hide a parameter, you'll need to use a UIHint
// UIHints can be used to accomplish a wide variety of things - for a full list, see the FeatureScript Library documentation
annotation { "Name" : "Bore size enum", "UIHint" : UIHint.ALWAYS_HIDDEN } // creates a hidden enum parameter
definition.boreSize is BoreSize;

// In order to get the editing logic working, you'll probably want to update the hidden BoreSize table whenever an input to it changes
// This would look something like this:
if {oldDefinition.input1 != definition.input1 || oldDefinition.input2 != definition.input2)
// compute BoreSize and set definition.boreSize

// The if condition keeps the calculations from running except when something that could actually affect it is changed. 
// Otherwise, it would get re-run every time a user makes any change to the UI, even if that change doesn't affect it at all

Hugh_Goodbody

@Alex_Kempen , Thanks very much for the tips, will see how I progress!