Micro-Nuggets !!! ~~~~ Post 'em if you got 'em

[albertm]

Hi,

I made and attached my VI that gets frequently needed CURRENT_USER and MACHINE folders from the registry like Common Docs and AppData.  I put 'Common' in the VI name which I think is a little confusing but I couldn't think of anything better.

I could not find this anywhere but I would think that many people could use this.  It's pretty simple but everyone should not have to write their own version of this.

Is this a good place for posting this?

Albert

[tst]

---

@albertm wrote:

I made and attached my VI that gets frequently needed CURRENT_USER and MACHINE folders from the registry like Common Docs and AppData.

---

I'm getting permission errors for some of the keys (the common ones, which I probably need to start LV with higher permissions to access) and key not found errors on some others.

In any case, some of these folders can be found using the Get System Directory VI from the file\constants palette.

[albertm]

I tested this only on XP assuming later OSes would support these.  I'll test it on a Windows 7 machine here.

I don't know what I could do about permissions.  I didn't consider that these would be protected since what really matters is access to the actual folder. 

Albert

[dan_u]

---

@tst wrote:

---

@albertm wrote:

I made and attached my VI that gets frequently needed CURRENT_USER and MACHINE folders from the registry like Common Docs and AppData.

---

I'm getting permission errors for some of the keys (the common ones, which I probably need to start LV with higher permissions to access) and key not found errors on some others.

In any case, some of these folders can be found using the Get System Directory VI from the file\constants palette.

---

The permission errors are because the key is read with the "security access mask" set to "KEY_READ | KEY_WRITE" instead of just "KEY_READ". Since in newer Windows versions the HKLM keys require elevation to be written they throw an error when opened with write access.

[albertm]

I incorrectly assumed the default was KEY_READ and I was helped by the help file that isn't clear about it in LV 8.2.1.  I'll post this change along with some I might make after testing this on Windows 7.

Thanks,

Albert

[albertm]

I fixed the permissions problem, added some comments, tested it under XP and Win 7, and attached it BUT, after doing some research, I found out that now you're supposed to get these folders by calling SHGetFolderPath().

I found some code at https://decibel.ni.com/content/docs/DOC-13632.  I modified that VI to make it a sub VI and attached it.  I only tested this under XP.  Oh yeah, you'll have to tell it where shfolder.dll is (c:\windows\system32).

Albert

[McTOM]

---

@shb wrote:

Why not use a flat sequence structure (with one frame)? It is inserted quicker (because the diagram is not disabled thereafter).

---

Indeed, it does the same job and might be quicker to insert, but the Diagram Disable borders are just 1 px thin. Talking about compactness here. 😉

After days of using this trick, I noticed that LabVIEW waits for all the input data to arrive before execution of the box, which is not the case when using Flat Frame. It might compromise the efficiency of the code.

I guess that to make this trick work flawlessly is to ask LV developers to make Diagram Cleanup respect the content of Flat Frame.

[tst]

---

@McTOM wrote:

...LabVIEW waits for all the input data to arrive before execution of the box, which is not the case when using Flat Frame.

---

Not exactly. Every frame in the flat sequence also waits on all the inputs before executing. The only exception for that is that earlier frames (let's say frame 0) can execute before inputs wired directly into later frames (let's say frame 3) arrive.

[McTOM]

tst, I was refering to the "Flat Frame" from Structures\decorations\.. , not a frame of "Flat Sequence".

I still think the "Flat Frame" makes no difference to the execution of the code. My only regret is that it is not properly supported by Clean Up Diagram.

[JÞB]

I just ran across a thread where a user was still using vits in an executable to launch asynchronous processes.  With modern versions of LabVIEW this is no longer necessary.  I even had an example project I had whipped up for some coworkers laying around.  So I thought maybe I'd better share that in a u-Nugget

Attched zips in 2012 and 2011.

Enjoy