Environment Variables in paths

[TaKend]

This should work!! I know there are workarounds and I have used them but it would be much easier.  

On Windows, you can define environment variables that auto expand to known directories. There are some variables that are already defined by the system. For example, %TEMP% automatically expands to c:\Users\<username>\AppData\Local\Temp OR WHEREVER THE USER MOVED TEMP DURING INSTALLATION. That's the important part .That makes it possible to write %TEMP%\abc as a symbolic path that works regardless of how the system gets reconfigured.

Users can define their own environment variables, and those get expanded when used in a path in the command line or Windows Explorer (the text entry region at the top of an Explorer window). On Linux and Mac, it is the equivalent of using $VARIABLENAME/abc, where VARIABLENAME is some user-chosen name.

[admin edit] Added background information on environment variables, and updated title to use the word "Environment" instead of "Environmental".

[RavensFan]

Can you clarify your idea a bit more?  What is %durangooxdk% supposed to mean?

[AristosQueue (NI)]

On Windows, you can define environmental variables that auto expand to known directories. There are some variables that are already defined by the system. For example, %TEMP% automatically expands to c:\Users\<username>\AppData\Local\Temp OR WHEREEVER THE USER MOVED TEMP DURING INSTALLATION. That's the important part .That makes it possible to write %TEMP%\abc as a symbolic path that works regardless of how the system gets reconfigured.

Users can define their own environment variables, and those get expanded when used in a path in the command line or Windows Explorer (the text entry region at the top of an Explorer window). On Linux and Mac, it is the equivalent of using $VARIABLENAME/abc, where VARIABLENAME is some user-chosen name.

[Hooovahh]

I like this idea, but I wonder how or if it would be supported on RT targets.  And how should it be handled if the variable name doesn't exist?  Just pass it as a string down the line and an error will be generated on whatever function tries to open it?  Or should it be turned into Not a Path?

[AristosQueue (NI)]

I would handle it the same way the OS handles it. On the three desktop platforms, those become empty strings.

[rd-car-o]

Did this ever get implemented? I just tried in 2021 and it doesn't work so I am guessing not.

[wiebe@CARYA]

>Did this ever get implemented? I just tried in 2021 and it doesn't work so I am guessing not.

Not as far as I know (the idea is still new, not implemented).

Here's a workaround I use:

I have wrappers around this that accept %APP% for my application path, and\or %CFG% for the application's configuration path. IIRC I even made a LUT in my config to specify custom variables. This is just a matter of a reg.ex...

[wiebe@CARYA]

I'm not sure if this conversion should always happen automatically.

Sometimes you want %system% + "test.txt" to result in "%system%\test.txt".

For instance, I  don't want my application to read "%temp%\a.txt", change the file name to "b.txt", and then store it as "C:\Users\durangooxdk\AppData\Local\Temp\b.txt". If Build Path would (always) do this automatically, this would be very hard to avoid when you don't want it. 

With an explicit resolve function the programmer has a choice.