Can LabVIEW "read" Microsoft Windows Environment Variables?

[Hooovahh]

---

@billko wrote:

---

---

I have to think it hasn't changed from "this_parameter=this_value".

---

Oh sorry let me be clear.  My software development skills 14 years ago were much less then they are today.  The code probably works, it just isn't a development style I think someone should try to replicate.

[billko]

---

@Hooovahh wrote:

---

@billko wrote:

---

---

I have to think it hasn't changed from "this_parameter=this_value".

---

Oh sorry let me be clear.  My software development skills 14 years ago were much less then they are today.  The code probably works, it just isn't a development style I think someone should try to replicate.

---

Oh, okay.  Yes I try not to look at code I generated a decade ago.  But sometimes it's useful to see your humble beginnings to see how far you've come.  But maybe best that it be a private viewing.  😄

[srlm]

---

@David_Grucza wrote:
Since I asked this question NI has added palette VIs for working wit Environment Variables.

---

What toolkit installs this palette? I do not see it in LV2020 installation. 

[MikeMesolella]

---

@srlm wrote:

---

@David_Grucza wrote:
Since I asked this question NI has added palette VIs for working wit Environment Variables.

---

What toolkit installs this palette? I do not see it in LV2020 installation. 

---

My theory is that David meant that some of these things are in the NI palettes. But you cannot access ALL of them without the.NET method that I posted. Perhaps I am wrong, I did a search just now and didn’t find anything either. 

[billko]

I just looked up all the list of variables on the MS website, dumped them into an enum and called the system exec.

[Martin_Henz]

I find it more convenient to use the Windows API.

[billko]

---

@Martin_Henz wrote:

I find it more convenient to use the Windows API.

---

Your solution is elegant; it was much simpler to program using system exec.

[srlm]

Many thanks.

[rolfk]

---

@Martin_Henz wrote:

I find it more convenient to use the Windows API.

---

Convinience is a matter of taste. 😁 I also prefer the Windows API path over .Net or command line tools.

.Net because of the additional overhead of interfacing between the LabVIEW managed environment and the siginificantly different .Net managed environment.

Command Line has the overhead of instantiating a separate process each time and while the cost for that under Linux is considerable, it is factors worse under Windows.

The Windows API is in process, direct and needs no extra invocation or marshalling. However it can require some parameter massaging and requires a fairly good understanding of C datatypes and how they are treated by a compiler.

[billko]

---

@rolfk wrote:

---

@Martin_Henz wrote:

I find it more convenient to use the Windows API.

---

Convinience is a matter of taste. 😁 I also prefer the Windows API path over .Net or command line tools.

.Net because of the additional overhead of interfacing between the LabVIEW managed environment and the siginificantly different .Net managed environment.

Command Line has the overhead of instantiating a separate process each time and while the cost for that under Linux is considerable, it is factors worse under Windows.

The Windows API is in process, direct and needs no extra invocation or marshalling. However it can require some parameter massaging and requires a fairly good understanding of C datatypes and how they are treated by a compiler.

---

I don't expect to hammer my computer with requests for environmental variables, so I don't really factor in the overhead.

I only factored in the simplicity of implementing the solution, not the cost.  All the info I needed was on one MS page.