Trying to figure out how to create a "dynamic" drop down list in Featurescript UI

eric_pesty

I'm trying to create a feature that will generate 2 variables (to be used for sheet metal): a thickness and a bend radius. 

I've setup a lookup table for material and gauges that also defines the available radius for the gauge (so far so good). I can pick the desired gauge in the UI and retrieve the thickness (and store in a variable), and I can also retrieve the vector of the compatible radii, but I'm stuck on how to generate a "pickable list" from these...

Here's an example entry from my lookup table:
"8GA" : {"Thickness":.1285 * inch, "Rads":[.08*inch,.125 *inch]},

Setting the thickness if fine:

        var thk is ValueWithUnits = getLookupTable(gaugeTable, definition.thickness).Thickness;

        setVariable(context, definition.pref~"_THK", thk);

I can set the radius to one of the values in the vector (gets set to .08" as expected in this case):

        var Rads = getLookupTable(gaugeTable, definition.thickness).Rads;

        setVariable(context, definition.pref~"_Rad", Rads[0]);

I would just like to have a drop down list in the UI where I would be able to choose between the values stored in Rads[]. It seems like it should be doable but I'm a bit confused by dropdowns and how "convoluted" they have to be... I know how to create an "enum" with all the possible radii but I would need to restrict the available options based on the picked gauge and I'm not sure how to do this... 

Any thoughts?

lemon1324

Can you not just push your lookup one level deeper? That is, rather than have the terminal nodes of the table be something consisting of a thickness and an array of radii, returning something like {T, [R R R]} ), have another lookup table level to directly select a radius, and then the actual terminal nodes are just a thickness and radius parameter, returning something like {T, R}.

I've done a lookup table somewhat like this in my T-Slot joint feature - it doesn't sound to me like you need the table to be dynamically generated at runtime, just set up ahead of time.  One thing I did was write a quick python script to actually generate the lookup table itself, so modifying the table is easier, and it's also easier if you have different radii--even different numbers of radii--possible for each thickness.

konstantin_shiriazdanov

I don't think this dynamic generation of dropdown kind of input is possible with FS, data structures like enum or lookup table cannot be created in runtime, though it would be cool to have. One of the solutions - to display those possible values with reportFeatureInfo() for example and to have some count type input parameter which would allow user to pick array entry by index. More complicated solution is to dynamically create list input parameter with entries corresponding to the array values, with additional checkbox to distinguish user-selected entry. This would require to handle this in editing logic function.

eric_pesty

@konstantin_shiriazdanov, thanks for the input,
I had to lookup editing logic functions. I figured out a way to have checkbox that picks an "alternate radius" (i.e. use [1] instead of [0]) so I've made some sort of progress. Obviously this only works if there are always exactly two possible values for radii but it's not very flexible and it's done by overwriting a "length input" value that is showing up and can be input (which results in overriding the values from the table).
I'm a bit unsure what you mean by a dynamic "list input parameter" (although that sounds like what I'm trying to do...) Is that defining an "enum" inside the editing logic function?

lemon1324

Can you not just push your lookup one level deeper? That is, rather than have the terminal nodes of the table be something consisting of a thickness and an array of radii, returning something like {T, [R R R]} ), have another lookup table level to directly select a radius, and then the actual terminal nodes are just a thickness and radius parameter, returning something like {T, R}.

I've done a lookup table somewhat like this in my T-Slot joint feature - it doesn't sound to me like you need the table to be dynamically generated at runtime, just set up ahead of time.  One thing I did was write a quick python script to actually generate the lookup table itself, so modifying the table is easier, and it's also easier if you have different radii--even different numbers of radii--possible for each thickness.

eric_pesty

@lemon1324
Thanks, that was so obvious I completely missed it...
It will just make it a bit more cumbersome to generate all the data but it should be pretty static so I can live with that!

konstantin_shiriazdanov

eric_pesty said:

I'm a bit unsure what you mean by a dynamic "list input parameter" (although that sounds like what I'm trying to do...) Is that defining an "enum" inside the editing logic function?

I meant array input parameter - see the arrays section. If you setup the array entry like this:

{
 "radius": ValueWithUnits,
 "isSelected": boolean
}

and have a hidden definition field : definition.radius

then in editing logic you can find the entry whose "isSelected" field is changed from "false" to "true", and extract its radius value into definition.radius, which would later be accessible from feature body.

if (size(definition.entries)==size(oldDefinition.entries))
{
var selectedEntry;
var selectedIndex;
for ( var i = 0, i < size(definition.entries), i+=1 )
{
 const condition = oldDefinition.entry.isSelected == false && definition.entry.isSelected == true;
 if (condition)
 {
   selectedEntry= definition.entries[i];
   selectedIndex= i;
   break;
 }
}

if (selectedEntry != undefined)
 definition.radius = selectedEntry.radius;

//and here we unselect all entries whose index is not equal to selectedIndex
 for ( var i = 0, i < size(definition.entries), i+=1 )
   definition.entries[i].isSelcted = (i == selectedIndex);
}

eric_pesty

@konstantin_shiriazdanov, thanks for the clarification.
I'll keep that in mind if I run into a similar situation. I implemented the extra "level" as suggested by @lemon1324 and it works great. It's arguably slightly less "elegant" as you have to generate more entries in the lookup table but it only took about 20min to generate all of it so really not a big deal in this case (compared to implementing/debugging) the array option!