Welcome to the Onshape forum! Ask questions and join in the discussions about everything Onshape.

First time visiting? Here are some places to start:
  1. Looking for a certain topic? Check out the categories filter or use Search (upper right).
  2. Need support? Ask a question to our Community Support category.
  3. Please submit support tickets for bugs but you can request improvements in the Product Feedback category.
  4. Be respectful, on topic and if you see a problem, Flag it.

If you would like to contact our Community Manager personally, feel free to send a private message or an email.

Featurescript Lookup Table in UI

Hugh_GoodbodyHugh_Goodbody Member Posts: 30 PRO
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?

Comments

  • NeilCookeNeilCooke Moderator, Onshape Employees Posts: 3,691
    Yes, you can just nest another "entries" below the "20" entry. See the Beams feature for examples.
    Director, Technical Services, EMEAI
  • Hugh_GoodbodyHugh_Goodbody Member Posts: 30 PRO
    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?
  • NeilCookeNeilCooke Moderator, Onshape Employees Posts: 3,691
    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.
    Director, Technical Services, EMEAI
  • Hugh_GoodbodyHugh_Goodbody Member Posts: 30 PRO
    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_1kevin_o_toole_1 Onshape Employees, Developers, HDM Posts: 522
    @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_GoodbodyHugh_Goodbody Member Posts: 30 PRO

    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_KempenAlex_Kempen Member Posts: 49 EDU
    @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.

    I'm on the internship hunt
    My FeatureScript blog
    [email protected]
  • Hugh_GoodbodyHugh_Goodbody Member Posts: 30 PRO
    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_KempenAlex_Kempen Member Posts: 49 EDU
    edited March 4
    @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.

    I'm on the internship hunt
    My FeatureScript blog
    [email protected]
  • Hugh_GoodbodyHugh_Goodbody Member Posts: 30 PRO
    @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_KempenAlex_Kempen Member Posts: 49 EDU
    edited March 8
    @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
    
    

    I'm on the internship hunt
    My FeatureScript blog
    [email protected]
  • Hugh_GoodbodyHugh_Goodbody Member Posts: 30 PRO
    @Alex_Kempen , Thanks very much for the tips, will see how I progress!
Sign In or Register to comment.