Featurescript: Setting parameters to optional

ry_gb · December 16

Let's say I create a feature and then want to import it into another ~~studio~~ feature studio for use. Is there a way to make some of the definition parameters optional?

Edit: edited for clarity

_anton · December 16

Really, all parameters are optional unless they're used in the code of the feature. If you want the UI to communicate that a parameter isn't used, you can use if statements to hide it.

ry_gb · December 16

Edit: argh. I didn't mean to mark this as an answer, but i can't undo that. Everyone else answered very well.
I guess I should expand a bit more. I've been working on the Loft Fillet featurescript that I posted a while back. And as an added feature, I've also been working on an option to auto-match connections inside of it. It's starting to look like Auto Loft Connections might be a useful standalone feature by itself as well. I could just copy the code from Auto Loft Connections, turn it into a function inside of Loft Fillet. However, it would be rather tedious to keep up in both files should I ever change the code from Auto Loft Connections and the function inside of Loft Fillet.

I'm not entirely sure what Auto Loft Connections will end up looking like yet, but I'm wondering if there's a way to set myself up so I only need to change the code in one script and then deal with the ramifications on the dependent scripts after that. Would it be better to set up a third feature studio and import them both into Auto Loft Connections and Loft Fillet?
Secondly, how does that get implemented in the standard library functions? For example, in opExtrude, startBound is stated as optional, but as far as I can tell, there's no boolean or if statement driving it? Unless there's something in the internal code that I'm not aware of.

MichaelPascoe · December 16

You can conditionally show and hide UI like this: https://cad.onshape.com/documents/c7c08274a0d273b9a5f5b47d/w/f348f21ad2fa5c8771f1e1b1/e/0abb9be049d15f1839c40841

This can be controlled manually when you insert functions, or dynamically with either user choices or edit logic.

.

jelte_steur_info · December 16

If you create an opCreateMatchConnections function separately in its own feature studio in a document, you would be able to import it in AutoLoftConnections as well as the Loft fillet feature and get the benefit of version control where you might update it in one feature and deal with ramifications while the other one stays put until you get to updating it there.

I think the ‘optional’ functions all have a default or fall-back setting for if the argument is undefined.
In your opExtrude example (speculating here): if (definition.startBound != undefined)
{offsets the starting faces or edges by startBound value}

So if startBound is not used, it’ll still just work with the original faces or values…

these were my 2 cents. Would be very curious to hear what @Caden_Armstrong’s advice is on this matter of when/how to split functions into their own feature studio.

EvanReese · December 16

@ry_gb I'd get the key steps put into their own functions, which can be used as needed in either feature. Those functions could live entirely in their own feature studio and be imported to the feature studio for Loft Fillet and Auto Loft Connections.

As for conditional UI things others have covered it, but you just need to write your code in such a way that it doesn't fail if they don't use a certain field. For example if you have an optional query parameter you might do this

if(isQueryEmpty(context, definition.pointReference))

{

// If the query is empty, decide how to proceed without it. Maybe you don't need to do anything special, or maybe you wanna set it to something like this

definition.pointReference = qOrigin(EntityType.BODY);

// OR

definition.pointReference = qNothing();

}

else

{

// Do whatever you want to use the reference

}

_anton · December 16

Really, all parameters are optional unless they're used in the code of the feature. If you want the UI to communicate that a parameter isn't used, you can use if statements to hide it.

ry_gb · December 16

Edit: argh. I didn't mean to mark this as an answer, but i can't undo that. Everyone else answered very well.
I guess I should expand a bit more. I've been working on the Loft Fillet featurescript that I posted a while back. And as an added feature, I've also been working on an option to auto-match connections inside of it. It's starting to look like Auto Loft Connections might be a useful standalone feature by itself as well. I could just copy the code from Auto Loft Connections, turn it into a function inside of Loft Fillet. However, it would be rather tedious to keep up in both files should I ever change the code from Auto Loft Connections and the function inside of Loft Fillet.

I'm not entirely sure what Auto Loft Connections will end up looking like yet, but I'm wondering if there's a way to set myself up so I only need to change the code in one script and then deal with the ramifications on the dependent scripts after that. Would it be better to set up a third feature studio and import them both into Auto Loft Connections and Loft Fillet?
Secondly, how does that get implemented in the standard library functions? For example, in opExtrude, startBound is stated as optional, but as far as I can tell, there's no boolean or if statement driving it? Unless there's something in the internal code that I'm not aware of.

MichaelPascoe · December 16

You can conditionally show and hide UI like this: https://cad.onshape.com/documents/c7c08274a0d273b9a5f5b47d/w/f348f21ad2fa5c8771f1e1b1/e/0abb9be049d15f1839c40841

This can be controlled manually when you insert functions, or dynamically with either user choices or edit logic.

.

jelte_steur_info · December 16

If you create an opCreateMatchConnections function separately in its own feature studio in a document, you would be able to import it in AutoLoftConnections as well as the Loft fillet feature and get the benefit of version control where you might update it in one feature and deal with ramifications while the other one stays put until you get to updating it there.

I think the ‘optional’ functions all have a default or fall-back setting for if the argument is undefined.
In your opExtrude example (speculating here): if (definition.startBound != undefined)
{offsets the starting faces or edges by startBound value}

So if startBound is not used, it’ll still just work with the original faces or values…

these were my 2 cents. Would be very curious to hear what @Caden_Armstrong’s advice is on this matter of when/how to split functions into their own feature studio.

EvanReese · December 16

@ry_gb I'd get the key steps put into their own functions, which can be used as needed in either feature. Those functions could live entirely in their own feature studio and be imported to the feature studio for Loft Fillet and Auto Loft Connections.

As for conditional UI things others have covered it, but you just need to write your code in such a way that it doesn't fail if they don't use a certain field. For example if you have an optional query parameter you might do this

if(isQueryEmpty(context, definition.pointReference))

{

// If the query is empty, decide how to proceed without it. Maybe you don't need to do anything special, or maybe you wanna set it to something like this

definition.pointReference = qOrigin(EntityType.BODY);

// OR

definition.pointReference = qNothing();

}

else

{

// Do whatever you want to use the reference

}

ry_gb · 1:17AM

Thank you all. These are all great answers. Seems pretty simple, but you need to be very explicit in how different inputs are entered.

Featurescript: Setting parameters to optional

Best Answers

Answers

Howdy, Stranger!

Quick Links

Categories