Environment variable token

[Pfeil]

With the implementation of {STATE_SYSDIR} and {STATE_WINDIR}, and the mentioning of performance overhead related to automatically parsing environment variables, I'm wondering if it would make sense to have a token to explicitly parse environment variables instead(or additionally).

E.G.

Code: [Select]

{ENVVAR:%windir%}
This would allow the use of any given environment variable, without having to check for them in every given string(assuming the overhead of parsing a token is lesser).

[Gary]

Actually, I think if you try, '{STATE_ENV:textValueOrTokenNotAVariable}', it will resolve to the process environment variable (not documented).
I started adding it, but there are actually environment variables that apply to proccess/user/machine.  I may split it up into 3 tokens:  {STATE_ENVPROCESS:textValueOrTokenNotAVariable}, {STATE_ENVUSER:textValueOrTokenNotAVariable}, {STATE_ENVMACHINE:textValueOrTokenNotAVariable}
if needed.

[Pfeil]

I can't seem to get that token to work, it always returns blank(I'm assuming it's a passthrough to "Environment.GetEnvironmentVariable()", so I tried "{STATE_ENV:WINDIR}" among others).

It does seem the most relevant context is Process, as more commonly used variables like "%USERPROFILE%" don't return a value for Machine or User(the latter of which I found odd, but then I'm not that familiar with the subject matter).

[Gary]

I started to add it with the new tokens but I was thinking it might have been a little confusing given that it can have three states.  It seemed like it would be good to add at first, but if it was just going to cause confusion it would be better to just leave it out for now.  I'll look into it more now that I know there is at least some interest in it.

[Gary]

Where I left it when testing different things out was, 'User'.  I'm going to leave it at the default of, 'Process' and if anybody has a need for the other two contexts, I'll revisit

[Pfeil]

"{STATE_ENV:}" does exactly what I wanted; Thanks, Gary