Define Variables as Constant

[RayFarmer]

It would be nice to beable to define a variable as constant.This could apply to Locals, FileGlobals, StationGlobals.

Once set mark it so as to be easily identifible as a Const.

The API would also need to include either a Property or Method so that one could determine if a variable is a Constant.

[dug9000]

Please elaborate on what the advantage of doing this over just having a regular variable would be to help us better understand the use case.

-Doug

[asbo]

I was looking for this just the other day. We have, for example, a Network Port test where the test is essentially a For Each Locals.NetworkPorts. Admittedly, we could hard-code this array into the For Each step itself, but I think it provides a little better clarity to have as a Local. Moreover, setting it to be a constant ensures that it cannot be inadvertantly changed, at development time or at run-time. I tried using the Not Edittable property but that apparently doesn't mean what I thought it did - am I wrong?

Our customer has access to our test limits file and we only expose specific Local variable names to them, but should they happen to be playing around and guess the name of something important, they could completely change/invalidate the test.

[RayFarmer]

Hi Doug,

Yes we can use a standard variable to act as a constant and when you are working as part of a team this can easily be handled. But when you are part of a team then it doesn't matter how many comments are used to signify that its a constant / read only / dont changed, there's always the chance it's value does get changed during program execution. Then tracking that instance of change down could be a nightmare especially if its buried in some code module. Much better to throw an error if someone tries to write to a variable set as a constant.

regards

Ray

[AllenP]

How would you ever be able to change this value at development time?  I'd imagine there would be cases where you might want to change it.  Would an "are you sure?" type dialog be enough.  Runtime cases are easy enough to distinguish that it should never be changed then.

[asbo]

I agree, there are cases where these might need to change at development time. A confirmation prompt might be enough, but it might be even better if editing the value had a greater impediment. I'm thinking something like disallowing the developer to change the constant like any other variable (i.e., by clicking in the Value column) and adding a new item in the context menu called "Edit Constant" which was put focus into the Value column and only allow changes through that method. Perhaps that's a bit unwieldy, though.

[RayFarmer]

I would think just a simple prompt would be enough so as to bring to the action that this is a constant.

[RayFarmer]

If constants are required and you want some traceability to a requirement maybe they should have a Requirements property.

[Eugene12]

"If constants are required and you want some traceability to a requirement maybe they should have a Requirements property."

This can be acomplished by using the expression statement in the present software together with the Requirements Gateway package. Instead of simply only assigning constants to a Local variable or File Global, we can force the assignment of the constant to stand out far better by also using individual expression statements for each requirement. This looks like something we should start doing right away as a Best Practice since the expression statement already has a Requirements property.

It seems that using Property Loader can also be useful.

Eugene

[pwaszkewitz]

I missed constants a lot in our recent projects. As for the use case: a typical example for us is the states our TestStand systems communicate back to the machine control system and the commands they receive from there. These are basically just numbers, like a number for "Ready", another for "Running" state, or a number for "Start", another for "Stop" etc.That is exactly the way you would use a #define in C (or, better, a const or an enum) to name the commands given to a device driver.

I like those numbers to have names, making them more easily usable for the application engineers. Currently we do that by defining a container type with all the distinct values as individual members with the correct numbers as the default. But of course you can assign to an instance of this container type, and I would like to make the values hard to change. A prompt may do that, but I would prefer to have values that can only be changed in the type editor. That would, in my eyes, mimic the behavior of a const or enum in C: you can change it in the header (i.e., the type editor), but not in the program (i.e., the sequence).

Peter

[mavimi]

I second the use case of pwaszkewitz

Magnus