Can LabVIEW "read" Microsoft Windows Environment Variables?

[maxnoder1995]

I wrote a function that finds the value of an environment variable.
Do you think there is a better way? Sorry for the mess.

Same as you write in the cmd:
"echo My PC is %COMPUTERNAME% and user is %USERNAME%".

[Martin_Henz]

---

@maxnoder1995 wrote:

I wrote a function that finds the value of an environment variable.
Do you think there is a better way? 

---

Of course there is a better solution, The windows API function ExpandEnvironmentStrings.

[GerdW]

Hi Max,

---

@maxnoder1995 wrote:

I wrote a function that finds the value of an environment variable.
Do you think there is a better way? Sorry for the mess.

---

Unfortunately you forgot to downconvert your VI. (I prefer LV2019, others may be happy with "LV2021 or older".)

In your image I don't see anything that reads the value of an environment variable. All you seem to do is to parse/format predefined strings…

[MikeMesolella]

---

@maxnoder1995 wrote:

I wrote a function that finds the value of an environment variable.
Do you think there is a better way? Sorry for the mess.

Same as you write in the cmd:
"echo My PC is %COMPUTERNAME% and user is %USERNAME%".

---

I will have to look at the Windows API way that was mentioned. But the .NET API that I mentioned about 10 years ago in this thread is really the easiest and cleanest way to do it.

[MikeMesolella]

---

@Martin_Henz wrote:

---

@maxnoder1995 wrote:

I wrote a function that finds the value of an environment variable.
Do you think there is a better way? 

---

Of course there is a better solution, The windows API function ExpandEnvironmentStrings.

---

Just tried this, at least for me it did not work at all.

[Andrey_Dmitriev]

---

@MikeMesolella wrote:

---

@Martin_Henz wrote:

---

@maxnoder1995 wrote:

I wrote a function that finds the value of an environment variable.
Do you think there is a better way? 

---

Of course there is a better solution, The windows API function ExpandEnvironmentStrings.

---

Just tried this, at least for me it did not work at all.

---

Probably you using it in wrong way, for me it works:

[daveTW]

Hello Martin,

thank you very much for the VIs.

My first try of "GetEnvironmentVariables" failed with "PATH", so I had to set the initial string buffer size to 4096. Now it works with this long value string.

Btw. i didn't know that the LABVIEW- dll contains these cstr - functions. Thank you for the hint.

[Martin_Henz]

---

@daveTW wrote:

My first try of "GetEnvironmentVariables" failed with "PATH", so I had to set the initial string buffer size to 4096.

---

The VI GetEnvironmentVariable.vi is actually not perfect. If the buffer is not large enough, the Windows API function returns the needed buffer size. It should be implemented similar to ExpandEnvironmentStrings.vi

Here it is:

[MikeMesolella]

---

@Andrey_Dmitriev wrote:

---

@MikeMesolella wrote:

---

@Martin_Henz wrote:

---

@maxnoder1995 wrote:

I wrote a function that finds the value of an environment variable.
Do you think there is a better way? 

---

Of course there is a better solution, The windows API function ExpandEnvironmentStrings.

---

Just tried this, at least for me it did not work at all.

---

Probably you using it in wrong way, for me it works:

---

Yes, got it.... I really don't know why need to re-invent the wheel from my page 2 post from 11 years ago....

But Okay! Let MS deal with the mess in .NET just seems easier!

[rolfk]

---

@MikeMesolella wrote:

---

But Okay! Let MS deal with the mess in .NET just seems easier!

---

Complexity is relative. Yes using the Call Library Node is not as trivial as using a .Net node (if you can find the according method or property in the vast .Net namespace). You need to know what you are doing and can't just point and click something together hoping that it will not crash. But it is in fact just as easy as .Net if you know what you are doing. And in this particular case there aren't even complex parameter types, just simple C memory management constraints one needs to observe, and that the Microsoft API documentation clearly documents.

In .Net some of that complexity is hidden, in a lot of LabVIEW generated machine code that translates from the LabVIEW managed environment to the .Net managed memory environment, loading a vast .Net runtime in the background (admittingly already loaded in most situations at least partly) and that .Net assembly then translates from the .Net managed memory model to the unmanaged Win32 API to call finally the API that our Call Library Node earlier called too.

So yes it seems less complex if you struggle with correctly configuring a Call Library Node, but is in fact magnitudes more complex in runtime execution.