NI TestStand Idea Exchange

Showing results for 
Search instead for 
Did you mean: 

Add some OOP feature to a seqeunce

Status: New



It would be nice to make Sequences public or private within a SequnenceFile.

With this you where able to make powerful SequenceFiles librarys.  The biggest advantage of this

is you can show the consumer of the library only the "important" public sequences. The

private ones where invisible. This will help to avoid errors.






Sessions NI-Week 2017 2016
Feedback or kudos are welcome
Active Participant

This could be a really useful feature...

Copyright © 2004-2023 Christopher G. Relf. Some Rights Reserved. This posting is licensed under a Creative Commons Attribution 2.5 License.
Active Participant

It seems that the idea here is strictly to have the functionality to specify sequences in a sequence file as public or private such that they can or cannot be accessed from a sequence call outside of the sequence file. Private sequences can only be called from sequences within the same sequence file and Public sequences can be called from sequences in separate sequence files as well as from sequences within the same sequence file.


This is my interpretation of this idea, please correct me if my understanding is incorrect.

Manooch H.
National Instruments
Active Participant

Hi Mannoch


You have understood it right.




Sessions NI-Week 2017 2016
Feedback or kudos are welcome
Trusted Enthusiast

I can see this being very useful when providing re-useable sequence file with a set of public sequences

Regards Ray

Ray Farmer
Active Participant



This could greatly help creators of custom process models. You could distribute a 'tools' sequence file along with the custom process model to further enhance the customer's experience. 


If you're interested, this made me think other ideas that I rejected:

This could be implemented just for browsing for a sequence during a sequence call. But I could also see it being tied to the current password system for editing the file too.  If you open the file(even in the sequence editor for editing), it only displays 'public' sequences.  But once you unlock it, you see all sequences. This would differ from the current behavior of not being able to open the file if there is a password, so maybe an option in the file properties to toggle the behavior?


Now that I've written that, I don't think it's a good idea.  The current password system locks files entirely, and changing the password to only hide some items would be very confusing.


What if you could mark anything as public or private? (which probably means adding a flag to the property object similar to the 'hidden' flag) So not just sequences could be marked private, but also locals, file globals, station globals, step properties, etc.  Only if you unlock the sequence file (the type palette, the station globals file, etc.) would you see the properties. I see this being a display only property, just like the hidden property; you would still be able to access all items via the TestStand API.

This brings in another use case: to hide step properties from users of the step. The downside is that I could see it being very confusing for someone who got one of these files with hidden items and sees 'magic' happen.


Now that I've wrote that out, I don't think it should be applied to all objects, there's already a 'hidden' property that does 90% of what I've described. The only additional features would be that you need a password (instead of a checkable option) to see certain objects, and that you could have different passwords for different objects.  But I think the cost of development would be too high (and there are other things I'd rather see worked on).


Josh W.
Certified TestStand Architect
Formerly blue
Active Participant

Access scope for sequences would be great.


Currently we can only set hidden flag on a sequence. This way we can let the user know that he/she should not use it. But this not only will not prevent from using hidden sequences but also cause a lot of red exclamation marks in sequence calls.

Michał Bieńkowski

Someone devote his time to help solve your problem? Appreciate it and give kudos. Problem solved? Accept as a solution so that others can find it faster in the future.
Make a contribution to the development of TestStand - vote on TestStand Idea Exchange.