Best Practice for defining optional TestStand provided Function parameters in TestStand

[Captain_Jack]

Hi All,

Unfortunately, TestStands Help for omitting Optional Parameters covers everything BUT TestStand on this subject!

When using a Function call in a step, I'm wondering what the best practice is for handing optional inputs and outputs. Because leaving it blank is not an option, I've found that instead of creating a dummy local variables; i.e., Nothing, 0, "", or an equivalent value type that matches the parameter type seems to work okay. Effectively as long as the statement evaluates properly, you're good. 

For instance, the FindFile () function has optional inputs that aren't at the end and can't be left blank:

Boolean FindFile(String fileToFind, Boolean useCurSeqFileDir = True, [String PathToFile], Number promptFlag = 1, Number searchFlag = 1, [Out] [Boolean canceled], Boolean isCommand = False)

So the following: FindFile(Locals.Comp.DataFilePath, False, "", 3, 3, 0, False) works just fine during execution.

That said, is there any potential downside to doing the call this way?

[~jiggawax~]

I've never really given this much thought but you bring up a good point.  I always just do the default specified in the function description in the TestStand help.  Or if one is not specified then I use the data type default value. 

My assumption is that, just like in most languages, optional parameters will have a default value and use that default value internally.  On output parameters it doesn't matter because I just assume it gets assigned to the constant memory space (really the space in the step.TS properties that define the parameters) and once the step completes execution gets cleaned up.

I agree that NI should add it to the Ommitting Optional Parameters page in the help.

Cheers,