Add "Project Globals" and/or "Workspace Globals"

[crelf]

I've found that there's a hole in the global map in TestStand - often there's something that I want to access across a project or workspace instance, but not a station (this is especially true when developing on my laptop).  I know that there are work arounds for this issue, but none of them are elegant solutions IMHO.  I'd like to see workspace and/or project globals implemented.

[RayFarmer]

hi crelf,

are you saying you would have some setup in the workspace where you can specify which sequences/sequencefiles are able to shared FileGlobals and to beable to define which fileglobals are shared.

regards

Ray

[crelf]

Not really.  I've had more of a think about it:

Firstly, I'm thinking there's less merit having workspace variables - I'd be happy with just project variables.  So, let me explain the project variables more clearly: we can have sequences in a project (so they're essentially "owned" by the project) - if they can be aware that they're owned by a project then they should be able to see the project variables (add a new variable section between Parameters and Station Globals I guess).  Then all seqeunces in the project can access these variables.

Also, since a sequence can belong to more than one project, a project variables group should be populated for each project it belongs to.

Something like this:

I'm guessing that the globals would then be saved in the project file, which means source distribution would be so much easier and more easily traceable.

[RayFarmer]

I am not keen on having yet another area for variables, I think 4 is enough.

regards

Ray

[crelf]

---

Ray Farmer wrote:

I am not keen on having yet another area for variables, I think 4 is enough.

---

How about we get rid of Station Globals**?  Would that make project variables a good idea?  Sorry, but I don't understand why you think that the idea of project variables has no merit just because of the number of other types of variable - that doesn't make sense to me.  Maybe I'm missing something?  Or maybe I'm not explaining myself well enough?

Summary: I dislike using Station Globals - I only use them because I have to - which is because I don't have project variables.  I hate that, when working on two different projects on my laptop - often for different customers, they share a common varriable location.  I want variables that are encapsulated at the project level, not the PC level.

** I'm joking - I know station globals have their place.

[RayFarmer]

I don't think your idea has no merit and I haven't dismissed it. Its just I dont see a use case for it yet.

StationGlobals have the correct functionality, it's just that they get miss used because you dont have a mechanism to pass data between sequencefiles especially if you are using the MainSequence as your top level sequence in each separate sequence file.

[crelf]

Ok - maybe I misunderstood your "I am not keen on having yet another area for variables, I think 4 is enough." as dmissive.

As for StationGlobals having the "correct functionality", I don't agree.  Sure, you can use them, but they're not the right place for project variables.  For example, I'm working on two projects at the moment (again, for different clients), and the deployment means that they each get their globals as well as the others'.  There currently isn't anything I know of that covers this use case (use case = a developer that works on more than one TestStand project at a time - which I expect is fairly common).  <- please tell me if I'm doing this wrong, because I'd sure be happy to know of a better way 🙂

[EMR]

With all complements to Ray ;-)...  I have to agree that developing code across multiple customers while using the same development PC does lead to messy station globals at times, even when all that's there is some pretty generic system config stuff. 

My problem is not so much quanity, as 'state.'  i.e. I want to use the same variable name in both development tasks but don't want the same value... 

Stationglobals.CustomerRootPath = "C:\\ACME"  on Monday but Stationglobals.CustomerRootPath = "C:\\Bloomy"   on Tuesday....

I usually end up (1) having to constantly check the global to see which 'mode' I am in at the start of development chores, or (2) basing all my configuration settings off of some prefix that I identify as part of the currently-open-sequence-file/path name... which works grand, but is rather cumbersome when multiple files are concerned.

Maybe I'm just an odd duck use-case for juggling different TS development tasks on the same PC?

I'm not saying I'm thrilled by the idea of having to cart around the project file along with my sequences... but honestly?  Having some task-sensitive varibles tied to the project, would give me an excuse to make my project earlier, and use them more often during my development lifecycle.  But critiquing the utility of projects-as-a-whole I'll save for another time 🙂 

Now I'd be perfectly cool with the project variables flipping to station variables on Deployment... just not on my personal work-machine....  So maybe we just need N-copies of StationGlobals.ini with one flagged as 'active' on startup? (madness!)

Cheers,

--Elaine R

[crelf]

---

EMR wrote:

My problem is not so much quanity, as 'state.'  i.e. I want to use the same variable name in both development tasks but don't want the same value... 

Stationglobals.CustomerRootPath = "C:\\ACME"  on Monday but Stationglobals.CustomerRootPath = "C:\\Bloomy"   on Tuesday....

I usually end up (1) having to constantly check the global to see which 'mode' I am in at the start of development chores, or (2) basing all my configuration settings off of some prefix that I identify as part of the currently-open-sequence-file/path name... which works grand, but is rather cumbersome when multiple files are concerned.

Maybe I'm just an odd duck use-case for juggling different TS development tasks on the same PC?

---

You're not an odd duck Elaine 🙂  What you're describing is exactly the problem I have, except that I often forget to check my station global states until it's too late.

[Manooch_H]

crelf and all -

I can see the need for the functionality you've discussed on this idea. Although this functionality does not already exist in as seemless a manner as you might like, you might be able to achieve separation of StationGlobals on a per project basis by having an individual Cfg directory for each project.

As you may or may not know, you can customize the location where TestStand looks for the Cfg directory. Using this functionality, you can have a separate Cfg directory for each project, and when it is time to work on Project 1, you can have TestStand look at Project 1's Cfg directory. This Cfg directory would contain the StationGlobals.ini file that defines the StationGlobals that pertain to Project 1. When it's time to work on Project 2, you can have TestStand look at Project 2's Cfg directory which would contain the StationGlobals.ini file that defines the StationGlobals that pertain to Project 2. And so on.

You can customize the Cfg directory in TestStand manually from the Preferences tab of the Station Options dialog, or you can customize it manually through the registry, or you can customize it programmatically with an application that uses the TestStand API. The API call in particular would be Engine.SetConfigDirectory().

I understand that this isn't exactly what you are asking for but it might be a reasonable workaround until the functionality in question does become available (if at all).

Hope this helps.

- Manooch H.

[crelf]

Thanks Manooch - you're right, it's a workaround that works well - thanks for bringing it up here, as it might help out others who are looking to solve the issue.  Of course, I'm still pushing for project globals, because there's a whole lot more than station globals in the Cfg folder that I'll want to share 🙂