Featurescript - Allow Duplicate Precondition Conditional Parameters

owen_sparks

Hi folks.

I'd like to be able to declare the same conditional parameter multiple times in a FS precondition.

Example use case:-

Here I have a feature to make a hole for a connector.  On some parts I want to offer the option to surface mount it, or make it flush with the target part.  So I'd like to just have one "definition.IsFlush" option, one definition.addvoid" and one definition.targetpart".  Instead we need to use a unique names for each set of declarations which is messy and prone to errors later in the code. (It's not appropriate to offer these options for other selections so I can't just put them in the unconditional part.)

<code> if (definition.OperationType == DesiredPart.Connector_Bolt)<br>                {          <br>                    annotation { "Name" : "Flush" }  //Transforms Part such that top face is flush with targtet.<br>                    definition.IsFlush is boolean;<br><br>                        if (definition.AddConnectorBoltVoid)<br>                        {<br>                            annotation { "Name" : "Target Part", "Filter" : EntityType.BODY && BodyType.SOLID, "MaxNumberOfPicks" : 1 }<br>                            definition.TargetPart is Query; <br>                        }<br>                }          
 //Optional Parameters based on choice form horizontal enum    <br>

and later

<code> if (definition.OperationType == DesiredPart.Connector_Nut)<br>                {          <br>                    annotation { "Name" : "Flush" }  //Transforms Part such that top face is flush with targtet.<br>                    definition.IsFlush_Nut is boolean;<br><br>                        if (definition.AddConnectorNutVoid)<br>                        {<br>                            annotation { "Name" : "Target Part", "Filter" : EntityType.BODY && BodyType.SOLID, "MaxNumberOfPicks" : 1 }<br>                            definition.TargetPart_Nut is Query; <br>                        }<br>                }          
 //Optional Parameters based on choice form horizontal enum    <br>

Cheers,

Owen S.

MBartlett21

@owen_sparks

You could use if(definition.operationType == DesiredPart.CONNECTOR_NUT || definition.operationType == DesiredPart.CONNECTOR_BOLT) if you wanted the parameters to show for both CONNECTOR_NUT and CONNECTOR_BOLT. (|| is 'or')

owen_sparks

Much obliged @MBartlett21

That certainly makes good sense for the example.  I did try that but it's in danger of making the preconditions a bit of a jumble to maintain.  The intent is for this to grow into one big feature with many options so my guys only have one FS to install and one grey icon to find when they come to use it. At least until we have a way of making custom toolbars for FS...   As such some parameters might be good for operations a, b, e, and f where as the next are c, d, and z.  To save my brain in a years time even though it'll make the code longer I'd rather define parameters in a sequential list.

Cheers, Owen S.

kevin_o_toole_1

@MBartlett21 's workaround should work, assuming both specifications of that parameter are identical.

Another workaround is to use different ids at the two places (as you've done), and in your feature, add code like definition.TargetPart = definition.TargetPart_Nut

There is a fair amount of Onshape's internal code which relies on those parameter ids being unique, and it would be especially difficult to handle the case of two parameters with the same id but different specifications. For that reason I would not expect this particular suggestion to be implemented as suggested any time soon. 

Jake_Rosenfeld

@owen_sparks

The other thing you could do if you end up needing to keep them separate for simplicity is using editing logic to always update the hidden ones to match the one that is currently showing.  I can go into a more detailed explanation if you are curious about how to do this.

owen_sparks

@kevin_o_toole_1 @Jake_Rosenfeld

Thanks Gent's I'll have a read of the proper documentation before bugging you further! Got to RTFM before taking up people's time 

Bits of FS are beginning to click into place.  Feels a bit like the rush of using OS for the first time years ago, a sense of "ooh, this is useful, I can do stuff with this..."

Cheers, Owen S.

Jake_Rosenfeld

@owen_sparks

To save you a bit of time, the part of the FM that specifies what I am talking about is the "Editing logic function" section of this page.  Happy reading!

owen_sparks

Much obliged

Owen S.

mahir

Jake_Rosenfeld said:

@owen_sparks

...the part of the FM...

Without skipping a beat  

owen_sparks

Yeah, we should have a "vote comment of the day"  button next to the "vote up" button on the forum for such things!