NI TestStand Idea Exchange

Currently you can right click the insertion palette and change the position / menu items that are shown / hidden in the insertion palette from a context based dialog box. (can also be done from the same box in the type palettes view).

It would be useful to be able to modify this programatically.

Currently you can only programatically play with the typepalettefilelist from the engine property object and insert new ones or remove old ones.

If a sequence file is loaded that has a step type in it that is not currently loaded by a type palette file, then it shows up in the insertion palette (as it should do), but if the testexec.ini file says this should be set to "hide" then it is hidden.

Thoughts

Thanks
Sacha

I would love native support of regular expressions (PCRE regex) in TestStand expressions, with the ability to output captured groups.

For instance, hypothetically:

Number EvaluateRegex(String string, String pattern, Number indexToSearchFrom = 0, Boolean ignoreCase = False, Array CapturedGroups)

I have successfully implemented a sequence to perform Microsoft's version of regex evaluation...

...but it takes several steps and uses Microsoft's flavor of regular expression syntax. This is frustrating for me because I already use moderately complex PCRE expressions all the time, and Microsoft's syntax varies enough to present an additional learning curve. It's also much more cumbersome that just using a native TestStand function within an expression.

My idea is similar to this one, but I'm looking for a function. Whenever people ask for regex support on the forums, it seems that workarounds are presented using simple string functions, but these don't cover my more advanced use cases.

Since day one of using TestStand I have been looking for this feature and I have always wondered why it is absent.

Thank you,

Mr. Jim

A customer noticed odd behavior when modifying custom data types in TestStand.  After reproducing the behavior, I think it's a better product suggestion because it looks as if what the customer notices is more of a design choice implemented by our software developers than a feature that is not behaving correctly.

The customer, David, created a custom type called DavidsType which was composed of a container and within this container was a collection of strings:

He then created an instance of this type in his DavidTest.seq file under the file global variables.  He called the instance MyType.

Then he goes back to the Types pane and modifies the structure of the custom data type to include another string with a default value of "C".

However, when he goes back to view the already created instance of his data type (MyType) within the variables pane of DavidTest.seq, he notices that only the structure is updated and not the default value.

New instances of the custom data type, however, do show up with the default value as shown below by MyType_Instance2.

The problem is that the customer has many instances of this type that already exist within his code.  He would currently have to create new instances of each type to load the new default value or he would have to hunt down all of the current instances and enter the default value of the new string manually.  I understand that the structure is updated, but shouldn't we build/provide an option to scan current instances of the custom data type and update default values for the elements that are new to a custom data type's structure?

I understand that it is expected behavior to load the default values of a custom data type only with a new instance of said custom data type, but I think we should provide an option/tool/function to our customers which updates all preexisting instances with the default value as well as the change in structure to the current types.  Currently only the structure is updated with a null string.

Hello,

It would be nice if there were an easy means of programmatically loading a database schema for result processing.

Here's my context for asking:

We have a custom database schema that must be loaded on all of our stations and we'd prefer that it "just works" when our customized database result processing plugin is loaded.

I managed to accomplish this by studying the format of TestStandDatabaseSchemas.ini and writing a parser to insert our schema as necessary. This was a bit painful, though, and the possibility of the format changing without notice has crossed my mind.

Thanks as usual to the R&D team.  (Assuming this idea gets some traction!  )

Kind regards,

Mr. Jim

We found a need to customize the NI version of this step to give more functionality.  Our edits updates to allow multiple response text boxes (up to 10), and we added an option to configure the response to be a list controls rather than simple strings. Just added a Boolean to switch to list box and then the user just gives comma separated list of options with the default item first as the initial response string.

This is a simple change to the step and allows far greater flexibility for the step type (also it was easy to make the step upgradeable from the exiting step version maintainign the functionality if one or no string responses being used).

These features are very useful for collecting all UUT information during PreUUT rather than having to throw up popup after popup or create a custom module with a popup in it.  Would be great if these features could be included in the standard NI step.