Choosing inputs based on Lookup tables

DSPuzzles

Suppose I have a parameter definition.table based on the following lookup table:
"Color"
     "Reds"
          "Light Red"
          "Dark Red"
     "Blues"
          "Light Blue"
          "Dark Blue"

Is there a way of having definition.table determine whether or not a second parameter shows up in the feature UI, based on whether the user selected "Reds" or "Blues"? I can only seem to find a way of doing it for the very last item in the tree ("Light Red", "Dark Red", ""Light Blue", "Dark Blue").

Thank you very much!

kevin_o_toole_1

I think this is not possible right now. If you really need this functionality, you could take apart your lookup table and structure it as many nested "if" statements with their own dropdown menu, but this would remove the advantages (ease of creation, scalability, code reuse) that lookup tables gain you in the first place.

Possibly the best solution is just having the query always visible, perhaps with an error state set ( throw regenError("reason", ["queryParameterId"]) ) when one of the "Reds" is selected. This would indicate to the user that the feature needs the query filled out in this case, showing the "message" when they hover their mouse on the feature or the parameter.

MBartlett21

Disousa said:

Suppose I have a parameter definition.table based on the following lookup table:
"Color"
     "Reds"
          "Light Red"
          "Dark Red"
     "Blues"
          "Light Blue"
          "Dark Blue"

Is there a way of having definition.table determine whether or not a second parameter shows up in the feature UI, based on whether the user selected "Reds" or "Blues"? I can only seem to find a way of doing it for the very last item in the tree ("Light Red", "Dark Red", ""Light Blue", "Dark Blue").

Thank you very much!

@Disousa
I think so
Try something like this:

export const lookupTable = {
        "name" : "color",
        "displayName" : "Color",
        "entries" : {
                "Red" : color(1, 0, 0),
                "Blues" : {
                        "name" : "darkness",
                        "displayName" : "Darkness",
                        "entries" : {
                                "Light blue" : color(0.75, 0.75, 1),
                                "Dark blue" : color(0, 0, 0.75),
                            }
                    },
            }
    };

DSPuzzles

Thank you very much, but this is not what I mean. An example of what I need would be if the user selected "Reds" in the table, the interface would then show an additional element with, say, a query for a body after the lookup table. This would happen independently of whether or not the user selected "Light Red" or "Dark Red" in the full tree.

kevin_o_toole_1

I think this is not possible right now. If you really need this functionality, you could take apart your lookup table and structure it as many nested "if" statements with their own dropdown menu, but this would remove the advantages (ease of creation, scalability, code reuse) that lookup tables gain you in the first place.

Possibly the best solution is just having the query always visible, perhaps with an error state set ( throw regenError("reason", ["queryParameterId"]) ) when one of the "Reds" is selected. This would indicate to the user that the feature needs the query filled out in this case, showing the "message" when they hover their mouse on the feature or the parameter.

DSPuzzles

Thank you very much Kevin. I develop an open source toolkit for puzzle designers, and I seem to come across interface problems rather often, even for very simple things. FeatureScript is an incredible resource, it's flexibility is one of the main reasons I use OnShape, but I think it needs a bit of work on the interface coding methods. Is there a specific place to leave suggestions or feature requests for FeatureScript?

kevin_o_toole_1

Absolutely - You can always submit an improvement request for any improvement you'd like to see in Onshape. The more others vote on your improvement, the more likely we are to add this to Onshape!

connor_pinson

kevin_o_toole_1 said:

...you could take apart your lookup table and structure it as many nested "if" statements with their own dropdown menu, but this would remove the advantages...

Hi Folks, Hi again Kevin,
This topic is actually really important to me.  I've been trying to find an efficient way to implement Kevin's suggestion.  The UI of my custom feature is a high priority and I want to get more granularity with visibility conditions. The lookup tables will likely not change too much over time so I am okay with the loss of scalability this solution will incur.  So we want to get to an end result like this:

export const lookupTable = {"name" : "color",
        "displayName" : "Color",
        "entries" : {
                "Red" : {"name" : "darkness", //Red option
                        "displayName" : "Darkness",
                        "entries" : {
                                "Light red" : color(0.75, 0.75, 1),//typical followup decision for colors
                                "Dark red" : color(0, 0, 0.75),
                        }},
                "Blues" : {
                    //similar to red                       
                            },
                "Greens":{//also similar to red
                              }
                "Striped" : {   //different from other colors
                        "name" : "Stripe_Thickness",
                        "displayName" : "Stripe Thickness",
                        "entries" : {
                                "thin" : 1.546,
                                "thick" : {"name" : "Thick",
                                             "displayName" : "Even more",
                                             "entries" : {
                                        "super" : "foo",
                                        "aewrqewr" : "foofoo"
...
<br>

We have many color options, some of which are similar and require similar followup choices, while other colors like "striped" take you down a different decision tree, etc. I'm sure we can leverage the similarity of these choices and the Map methods to generate this lookup table, but I am unsure on the specifics and also how to access this lookup table if it is in a separate FS module from where it is called (is this the biggest problem?.)  I basically want to create a few arrays that contain different configuration options, and loop through them to nest the lookup table:

toString(colors[i]):{"name":"ColorOptions", "displayName":"Visual Options","entries":{}}};
     
 //Branch colors vs striped
     if(colors[i]!=="Striped"){

     //loop over color options if colored, then merge maps with currently empty "entries" map within current color
          for(var j=0;j<size(ColorOptions);j+=1){
          ((Entries.(keys(Entries)[0]))=mergeMaps(Entries[i].keys(Entries[0]),{toString(ColorOptions[j][0]):[i,j]})
          .....                                                                       //Each endpoint       ^^^^^
                                                                                      //is just an array or encoded string or something
          else{ for(var j=0;j<size(StripeOptions);j+=1){   //loop over stripe options 
}
export const lookupTable = {"name" : "color",
        "displayName" : "Color", "entries":Entries}
//High level choice
const colors=["red","blue","green","striped"]

//Conditional followup choices
const ColorOptions=[["Light","light"],["Dark","dark"],["VeryDark","verydark"]
const StripeOptions=[["Thick","thick"],[["Thin","thin"]]

var Entries={};

            //first loop creates empty color entries of the form:  
for(var i=0;i<size(colors);i+=1){                     //here
     Entries=mergeMaps(Entries,{

Any thoughts on this? I'm sure people have already done this, but I couldn't find a thread for it.  I could use suggestions with the overall structure/map building.  As far as using it, as a last resort I may have to run a script like this to print out the look up table and just copy paste into a FS file each time I want to update.

MBartlett21

Would adding an editing logic function that showed it conditionally solve this problem??

lemon1324

I don't think you need an editing logic function, actually, since you want to display/not display an extra parameter not itself part of the lookup table.

Each lookup selection can set multiple parameters at the lowest level (here's the documentation, and for an example check the lookup table in my T-Slot Joint FS), so I'm pretty sure that if each lowest-level selection also sets a dummy boolean/integer parameter that is hidden from the user, that parameter should be able to then control display of later parameters, or even later lookup tables.

If I get time to actually test this I'll post an update with code, but I'm pretty sure that should work.