Retrieve appropriate 'Documents and settings' (or home) folder

[tbd]

---

tst wrote:

To get to the APPDATA directory, you should use the recommended Windows way of calling SHGetFolderData instead of building and stripping, as this will work in different languages, versions, etc. 

---

Hi tst,

      It seems (in Raistlin's original post) that code portability across operating systems (Windows/Linux) might be desireable.  By using the DefaultDataDirectory program-constant he can achieve this.

Cheers.

Message Edited by tbd on 03-23-2007 05:24 PM

[tst]

Or you can create a different VI for each OS and call them dynamically using the conditional disable structure or the Application.OS property. More complex, but also more "correct".

[tbd]

Hi tst,

---

@tst wrote:
Or you can create a different VI for each OS and call them dynamically using the conditional disable structure or the Application.OS property. More complex, but also more "correct".

---

... just because you can, doesn't mean you should - and your assertion (re: 'more "correct"') seems rather ambitious.

If not this, then, under what situation would it be "correct" to exploit the cross-platform implementation of the DDD-constant?

To my mind, "complexity"  is one of many factors that determine "correct"ness, and the solution you suggest seems as "elegant" and "appropriate" as using a bull-dozer to sweep the floor - when a broom is within arms-reach!

Message Edited by tbd on 03-24-2007 06:44 PM

Message Edited by tbd on 03-24-2007 06:45 PM

Message Edited by tbd on 03-24-2007 06:46 PM

[tbd]

Sorry tst, "bull-dozer" comparison was not fair

 (and "arms-reach" should have been "arm's-reach"):smileywink:

[tst]

Generally, I would agree with you. Using a single property is much better than having to write a seperate VI for each platform and call it dynamically, etc. but in this case you should note that the intent was to get the DDD and then strip and build to get to the APPDATA folder, and that's bad form because the APPDATA folder could change places. Obviously, you can use the DDD itself for storing the data, but I don't like NI's decision of putting it inside My Documents instead of inside Application Data.

It's possible that I'm just more affected by other stuff I know. Try reading Raymond Chen's blog. He's a programmer from Microsoft who often talks about why certain things are the way they are in Windows and how MS does all kinds of tricks to fix the mistakes other people make so that the programs continue working nicely. It makes for an interesting read.

[Raistlin]

I do agree with the idea of avoiding work-arounds, and it's a pity LabVIEW does not point to the APPDAT folder. Especially if you take into consideration changes like for example Windows Vista. Maybe it's better to do things the right way immediately instead of trying a temporary work-around.

Message Edited by Raistlin on 03-25-2007 05:42 AM

[travispape]

By the way, it's "SHGetFolderPath" and here is an example implementation:  http://forums.lavag.org/System-Variables-in-Windows-t2785.html&pid=13084&mode=threaded#entry13084

---

@tst wrote:

To get to the APPDATA directory, you should use the recommended Windows way of calling SHGetFolderData instead of building and stripping, as this will work in different languages, versions, etc. 

I think I remember seeing an implementation on the LAVA forums.

---

Message Edited by travispape on 09-28-2007 11:56 AM