Reading Previous Feature Inputs

"Hey Caden, can a feature extract the parameters of a previous feature?"

-Simon Gatrall

I got this message in my inbox from a fellow Onshape expert/enthusiast, and my initial answer was... no. Onshape Features don't have access to information beyond the current state of the model, and their own inputs. Its part of what makes them secure. You can check out Simon's Improvement Request on the topic.

Except, they can if you want them to. If the previous feature is a custom feature that you wrote, you could store the inputs of the first feature, and retrieve them in the second feature.

Somewhere in your feature store the definition

setAttribute(context, {
                    "entities" : qOrigin(EntityType.BODY),
                    "name" : "MY_STORED_FUNCTION_NAME",
                    "attribute" : definition
                });

And then retrieve it later

var storedDef = getAttribute(context, {
	"entity" : qOrigin(EntityType.BODY),
     "name" : "MY_STORED_FUNCTION_NAME"
            });     

The specific use case was to have a feature duplicate the previous inputs to make it easier to quickly iterate. So I took the bridging curve feature from the Onshape std (yay open source), and made a copy of the inputs. I store the definition at the end of the function. But the inputs need to be set, so I created an editing logic function to set the inputs when the feature starts up (or checks off the "update" option).

export function EditingLogicFunction(context is Context, id is Id, olddefinition is map, definition is map, isCreating is boolean) returns map
{
    if (definition.update)
    {
        var storedDef = getAttribute(context, {
                "entity" : qOrigin(EntityType.BODY),
                "name" : "STORED_BRIDGE"
            });
        if (storedDef != undefined)
        {
            definition = storedDef;
        }
        definition.update = false;
    }
    return definition;
}

If you try out the feature, you'll see that subsequent iterative bridging curves copy the previous one's inputs, making it quick and easy to make small tweaks.

Check out the example here

But how does pattern and mirror work if they can't see the previous features?

Some of the curtain can be drawn back. Functions like lastModifyingOperationId can be used to retrieve the feature Id of previous features. So it is possible to see the result of another feature. But that still doesn't give us the inputs of that feature.

The "FeatureList" input type for a FeatureScript passes function references to previous features in the tree, but FeatureScript doesn't seem to allow us to expose the inputs of that function.

Fun thing I found while writing this: you can get the name of a feature with getFeatureName, but only in tables and editing logic functions.