How to inhibit precondition enums based on earlier entry.

owen_sparks

Hi folks.

Looking for some help regarding precondition enums, and specifically an elegant method of inhibiting some options depending on what is entered earlier.

Suppose we have one enum for drink type, and another for drink size

export enum Drink_Type

{

    annotation { "Name" : "FizzyPop" }

    POP,

    annotation { "Name" : "Juice" }

    JUICE,

    annotation { "Name" : "Beer" }

    BEER

}

export enum Drink_Size

{

    annotation { "Name" : "Small" }

    SMALL,

    annotation { "Name" : "Medium" }

    MEDIUM,

    annotation { "Name" : "Large" }

    LARGE

} 

annotation { "Name" : "Select Drink Type" }

definition.DrinkTypeChosen is Drink_Type;

                

annotation { "Name" : "Select Drink Size" }

definition.DrinkSizeChosen is Drink_Size;

Further suppose Beer is only available in Medium and Large.  (Who'd want a small beer anyway?)  

How do we take away the option for the user to pick a small beer?

The least terrible idea I've come up with so far is to have multiple enums populated as to what's available:-

export enum Drink_Size_Default

{

    annotation { "Name" : "Small" }

    SMALL,

    annotation { "Name" : "Medium" }

    MEDIUM,

    annotation { "Name" : "Large" }

    LARGE

} 

export enum Drink_Size_Beer

{

    annotation { "Name" : "Medium" }

    MEDIUM,

    annotation { "Name" : "Large" }

    LARGE

} 

if (definition.DrinkTypeChosen == Drink_Type.BEER ))

            {

                       annotation { "Name" : "Select Drink Size" }

                       definition.DrinkSizeChosen is Drink_Size_Beer;

            }

            else

            {

                       annotation { "Name" : "Select Drink Size" }

                       definition.DrinkSizeChosen is Drink_Size_Default;

            }  

Is this plausible?

Is there a cleaner more elegant method?

I think what I'm really after is something along the lines of-

     
if definition.DrinkTypeChosen = Drink_Type.BEER  then  enum Drink_Size.Small.hidden = true   

As ever, thanks for your help.

Owen S.     

lemon1324

That's definitely plausible for simple situations. 

I think the best way to get this behavior generally is to use a LookupTablePath as the annotation; also check the source for the hole feature.  This does mean you have to define a table, but that could be automated with your choice of scripting language, and if you need a lot of customization it will definitely be better than defining many enums.

kevin_o_toole_1

You're right, we don't have a great way of doing this right now. @lemon1324 has it spot on: There's two decent options.

Option 1 is to do essentially what you've proposed, with multiple enums. One issue that will come up is that you'll have to name the parameter itself different things in the different cases (see the feature UI docs).

To consolidate your enums back to a variable of one type, at the beginning of your feature you'll also need to add logic to convert back e.g.

definition.BeerSizeChosen != undefined)
    definition.DrinkSizeChosen =definition.BeerSizeChosen as Drink_Size_Defaultif (

Option 2 is using a LookupTablePath to create a full tree of options, all centered around one parameter (or set of params)

For example:

const oz is ValueWithUnits = 29.5735 * centimeter ^ 3;
export const sizeTable = {
        "name" : "region",
        "displayName" : "Region",
        "default" : "EU",
        "entries" : {
            "EU" : {
                "name" : "size",
                "displayName" : "Size",
                "default" : "medium",
                "entries" : {
                    "small" : 8 * oz,
                    "medium" : 12 * oz,
                    "large" : 16 * oz
                }
            },
            "US" : {
                "name" : "size",
                "displayName" : "Size",
                "default" : "large",
                "entries" : {
                    "medium" : 16 * oz,
                    "large" : 32 * oz,
                    "supersize" : 64 * oz
                }
            }
        }
    };

annotation { "Feature Type Name" : "Soda" }
export const soda = defineFeature(function(context is Context, id is Id, definition is map)
    precondition
    {
        annotation { "Name" : "Soda size", "Lookup Table" : sizeTable }
        definition.sizeTable is LookupTablePath;
    }
    {
        println(definition.sizeTable);
        var selectedRegion = definition.sizeTable.region;
        var selectedSize = definition.sizeTable.size;
        var size = sizeTable
                    .entries[selectedRegion]
                    .entries[selectedSize];
        println(size);

        fCylinder(context, id + "cylinder1", {
                "topCenter" : vector(0, 0, 0) * inch,
                "bottomCenter" : vector(0, 0, 1) * size ^ (1/3),
                "radius" : size ^ (1/3)
        });
    });

We are looking into ways of solving problems like this better on a high level (where feature options control one another), so if you could share your specific case (publicly here, or privately by emailing kotoole@onshape.com), we'd love to hear about it!

lemon1324

That's definitely plausible for simple situations. 

I think the best way to get this behavior generally is to use a LookupTablePath as the annotation; also check the source for the hole feature.  This does mean you have to define a table, but that could be automated with your choice of scripting language, and if you need a lot of customization it will definitely be better than defining many enums.

kevin_o_toole_1

You're right, we don't have a great way of doing this right now. @lemon1324 has it spot on: There's two decent options.

Option 1 is to do essentially what you've proposed, with multiple enums. One issue that will come up is that you'll have to name the parameter itself different things in the different cases (see the feature UI docs).

To consolidate your enums back to a variable of one type, at the beginning of your feature you'll also need to add logic to convert back e.g.

definition.BeerSizeChosen != undefined)
    definition.DrinkSizeChosen =definition.BeerSizeChosen as Drink_Size_Defaultif (

Option 2 is using a LookupTablePath to create a full tree of options, all centered around one parameter (or set of params)

For example:

const oz is ValueWithUnits = 29.5735 * centimeter ^ 3;
export const sizeTable = {
        "name" : "region",
        "displayName" : "Region",
        "default" : "EU",
        "entries" : {
            "EU" : {
                "name" : "size",
                "displayName" : "Size",
                "default" : "medium",
                "entries" : {
                    "small" : 8 * oz,
                    "medium" : 12 * oz,
                    "large" : 16 * oz
                }
            },
            "US" : {
                "name" : "size",
                "displayName" : "Size",
                "default" : "large",
                "entries" : {
                    "medium" : 16 * oz,
                    "large" : 32 * oz,
                    "supersize" : 64 * oz
                }
            }
        }
    };

annotation { "Feature Type Name" : "Soda" }
export const soda = defineFeature(function(context is Context, id is Id, definition is map)
    precondition
    {
        annotation { "Name" : "Soda size", "Lookup Table" : sizeTable }
        definition.sizeTable is LookupTablePath;
    }
    {
        println(definition.sizeTable);
        var selectedRegion = definition.sizeTable.region;
        var selectedSize = definition.sizeTable.size;
        var size = sizeTable
                    .entries[selectedRegion]
                    .entries[selectedSize];
        println(size);

        fCylinder(context, id + "cylinder1", {
                "topCenter" : vector(0, 0, 0) * inch,
                "bottomCenter" : vector(0, 0, 1) * size ^ (1/3),
                "radius" : size ^ (1/3)
        });
    });

We are looking into ways of solving problems like this better on a high level (where feature options control one another), so if you could share your specific case (publicly here, or privately by emailing kotoole@onshape.com), we'd love to hear about it!

owen_sparks

Thanks Gents, excellent information.

The benefits of the table method seem to outweigh the minor inconvenience of setting them up.

I really appreciate you guys taking the time to explain the process.

@kevin_o_toole_1 This is for a "Nut Pocket" featurescript that I said I'd have a go at.  (My first attempt at fs, so please don't expect much.)  I'll make my first stab at the problem public later today.

Cheers,
Owen S.

MBartlett21

owen_sparks said:

I'll make my first stab at the problem public later today.

@owen_sparks
Is the document public?
If so, what is the link I would use to get to it?

EvanReese

@owen_sparks
I'd definitely use the heck out of a feature like this. Did you end up getting it to a point you were happy with?

owen_sparks

Evan_Reese said:

@owen_sparks
I'd definitely use the heck out of a feature like this. Did you end up getting it to a point you were happy with?

@Evan_Reese
Sorry I became ill after posting this so real life got in the way.  After getting better I'm afraid I didn't get around to picking it up again.
Owen S.

EvanReese

owen_sparks said:

Evan_Reese said:

@owen_sparks
I'd definitely use the heck out of a feature like this. Did you end up getting it to a point you were happy with?

@Evan_Reese
Sorry I became ill after posting this so real life got in the way.  After getting better I'm afraid I didn't get around to picking it up again.
Owen S.

The important thing is that you're ok! I might take a stab at something similar in the future. It's a good concept.