I am trying to get to the Application Data folder user current user->Local. I
have looked at a few different functions and example but they don't work on
XP.

Is there a way to get to this special folder that works for 2000, XP and
Vista?

-Jalil

There are a couple of Win32API functions you can use.  My preference is
SHGetSpecialFolderPath.  This works in Win98 and above (actually, Win95 if
IE4 and the Desktop Update are installed).  Use the CSIDL constant
CSIDL_LOCAL_APPDATA. If you need example code, search the newsgroups at
http://groups.google.com/advanced_search.

Here's a link to the documentation for this function:

http://msdn.microsoft.com/en-us/library/bb762204(VS.85).aspx

Since you need to support older versions of  Windows, this is the function
you should use.  If you were targeting ONLY Vista or later, you should use
the SHGetKnownFolderPath function and the KNOWNFOLDERID constants.

In addition to MikeD's post there's this:

SHGetSpecialFolderLocation
http://vbnet.mvps.org/code/browse/shpathidlist.htm


  That seems to be the most widely-supported function,
and as far as I know it still works on Vista.


  And then there's this:

http://vbnet.mvps.org/code/browse/csidl.htm

  With the mish-mash of folder location functions that
developed, Microsoft created a small, redistributable DLL
(shfolder.dll) and then recommended that it be used to
standardize the process of getting folder paths on all
systems. This seems to be the method used by most
installers. With Inno, at least, I've seen that it unloads
a copy of shfolder.dll to the TEMP folder during install.

  You can get more info. from Randy Birch's pages at the
links above.

SHGetSpecialFolderPath is easier to use for a number of reasons.
SHGetSpecialFolderLocation returns a pidl from which you must then obtain
the path by calling SHGetPathFromIDList. You must also be certain to free
the pidl.

As I mentioned, SHGetSpecialFolderPath is implemented in Win98 and later, or
Win95/NT4 with IE4. Contrastly, SHGetSpecialFolderLocation does *not*
require IE4 under Win95/NT4. That's the only difference as for as support
under different versions of Windows.

Show quoteHide quoteYou seem to be under a slight misconception about why MS created
SHFolder.dll.  It basically just added a few functions introduced in Win98
to Win95 without the IE4 dependency (because SHFolder.dll was
redistributable). It was created so apps wouldn't need two "sets of code" to
get special folders, depending on if the app was run under Win95 or Win98.

SHFolder.dll only supports a few functions and limited CSIDL constants.
Given the versions of Windows for the above 2 functions
(SHGetSpecialFolderPath and GetSpecialFolderLocation), there's little reason
nowadays to use SHFolder.dll.

Show quote Hide quote   Yes, so it's as I said. SHGetSpecialFolderLocation is the
most widely supported. Older versions of Windows may
not matter to most people, but it's worth knowing the
difference. SHGetSpecialFolderLocation is not especially
difficult to use. I do like that SHGetSpecialFolderPath has
the option to create the folder, though.

Show quoteHide quote   You may be right. I'm no expert on this. But it's not what
Randy Birch seems to say:

----------
SHGetFolderPath is a superset of SHGetSpecialFolderPath
included with earlier versions of the Windows shell.
SHGetFolderPath is implemented in a redistributable DLL,
SHFolder.dll, that also simulates many of the new shell
folders on older platforms such as Windows 95, Windows
98, and Windows NT 4.0. In degrading, this DLL always
calls the current platform's version of this function to
assure success, and if that fails, it will try to simulate the
appropriate behaviour.

Microsoft recommends the use of SHGetFolderPath as
a Best Practice....
-----------

  I was under the impression that MS was updating shfolder.dll
so that it would always be well-suited to all systems without
needing to deal with other calls. The version on my system
currently (Win98SE) is from 2002.
  I haven't actually used it myself, though. It seems a bit
excessive to ship an extra DLL. It also makes me nervous
that it "simulates newer shell folders on older systems". That
sounds a bit like the Vista virtualization problem of Windows
deciding what's best without telling the function caller.

Show quote Hide quote Well, if supporting Win95 or NT4 is necessary for your app, then I guess
you're right.  <g>  I will concede that IF you need to support those OSs,
it'd be best NOT to rely on IE4 being installed (such that you could just
use SHGetSpecialFolderPath regardless). I also didn't say
SHGetSpecialFolderLocation was "especially difficult" to use.  I said
SHGetSpecialFolderPath was easier to use.  <g>

Wouldn't it be nice if:

  path = Environ("APPDATA")

was reliable?

LFS

Jalil wrote:
See: http://vb.mvps.org/samples/SysFolders

  An interesting finding:

  After the earlier discussion I thought maybe I'd switch
from using SHGetSpecialFolderLocation to using
SHGetSpecialFolderPath. With your code loaded I decided
to add that approach to your project in order to
have a total sample. Surprisingly, SHGetSpecialFolderPath
doesn't return as many paths. Most important, it doesn't
return Program Files!
  On Win98SE I ran a function to call each method with
folder IDs from 0 to 68. The ones that were returned by
SHGetSpecialFolderLocation but were NOT returned by
SHGetSpecialFolderPath were as follows:

CSIDL_COMMON_PROGRAMS - C:\WINDOWS\All Users\Start Menu\Programs
CSIDL_COMMON_APPDATA - C:\WINDOWS\All Users\Application Data
CSIDL_WINDOWS - C:\WINDOWS
CSIDL_SYSTEM - C:\WINDOWS\SYSTEM
CSIDL_PROGRAM_FILES - C:\Program Files
CSIDL_MYPICTURES - C:\My Documents\My Pictures
CSIDL_PROGRAM_FILES_COMMON - C:\Program Files\Common Files

And actually it's worse than that. If I create the
folder Locall Settings\Application Data then that's
returned for CSIDL_LOCAL_APPDATA by
SHGetSpecialFolderLocation, but not by
SHGetSpecialFolderPath. So apparently there are
a number of other folders that may or may not
exist on some systems, but which SHGetSpecialFolderPath
won't return.

   I don't know whether SHGetSpecialFolderPath is more
limited or whether it just doesn't look for some folders on
Win9x. But both functions have to be the same vintage
because they both come from shell32. And these folders
are all standard on Win9x, with the exception of
CSIDL_COMMON_APPDATA. So the behavior of
SHGetSpecialFolderPath doesn't seem to make sense.

(I'm assuming both of those functions still work
on Vista/7, despite Vista/7 also having its own
newer version.)

mayayana wrote:
That is bizzare, alright.  Not sure what to make of it.  The SHGetSpecialFolderPath
specifically states that it will fail with virtual folders, but none of the ones
you're doing that with are those.  Huh.  Well, I originally went with
SHGetSpecialFolderLocation many, many moons ago, and I guess there actually /was/ a
make this switch?
Show quoteHide quote

   No. I have existing code that uses SHGetSpecialFolderLocation,
and that's the most widely supported. Then MikeD pointed
out that SHGetSpecialFolderPath has been around almost as long
and is simpler. And it also provides a handy option to create the
folder. So I thought that maybe I'd change my code. But of course
the ability to create the folder isn't much good with a function
that doesn't know about the folder!

mayayana wrote:
Doesn't SHGetSpecialFolderLocation honor CSIDL_FLAG_CREATE?

But yeah, shortcuts that end up getting you lost don't save a lot of time, do they?
<g>

Ah. It does:

http://vbnet.mvps.org/code/browse/shpathidlist.htm

  I never noticed that, and there's no mention of it
in my copy of MSDN. Also, your code implied that it's
not possible by the fact that it only offering the option
of creating the folder with the Vista call.

If m_Enhanced Then
      ' Tell system to create, if necessary
      If ForceCreation Then
         CSIDL = CSIDL Or CSIDL_FLAG_CREATE
      End If

.....

OK, I just tested this and got more strange results.
Using
   i Or CSIDL_FLAG_CREATE Or CSIDL_FLAG_DONT_VERIFY

for the CSIDL value, I now get several new folders,
including All Users\Documents and an Administrative Tools
folder on my Win98 Start Menu. (That should come in handy. :)

  But SHGetSpecialFolderPath still doesn't see any of those
new folders. Here's what I get, after all folders are created,
with SHGetSpecialFolderPath (21 paths):

0 - C:\WINDOWS\Desktop
2 - C:\WINDOWS\Start Menu\Programs
5 - C:\Save Folder
6 - C:\WINDOWS\Favorites
7 - C:\WINDOWS\Start Menu\Programs\StartUp
8 - C:\WINDOWS\Recent
9 - C:\WINDOWS\SendTo
11 - C:\WINDOWS\Start Menu
16 - C:\WINDOWS\Desktop
19 - C:\WINDOWS\NetHood
20 - C:\WINDOWS\FONTS
21 - C:\WINDOWS\ShellNew
22 - C:\WINDOWS\All Users\Start Menu
23 - C:\WINDOWS\All Users\Start Menu\Programs
24 - C:\WINDOWS\All Users\Start Menu\Programs\StartUp
25 - C:\WINDOWS\All Users\Desktop
26 - C:\WINDOWS\Application Data
27 - C:\WINDOWS\PrintHood
32 - C:\WINDOWS\Temporary Internet Files
33 - C:\WINDOWS\Cookies
34 - C:\WINDOWS\History

And here's what I get with SHGetSpecialFolderLocation (31 paths):

0 - C:\WINDOWS\Desktop
2 - C:\WINDOWS\Start Menu\Programs
5 - C:\Save Folder
6 - C:\WINDOWS\Favorites
7 - C:\WINDOWS\Start Menu\Programs\StartUp
8 - C:\WINDOWS\Recent
9 - C:\WINDOWS\SendTo
11 - C:\WINDOWS\Start Menu
16 - C:\WINDOWS\Desktop
19 - C:\WINDOWS\NetHood
20 - C:\WINDOWS\FONTS
21 - C:\WINDOWS\ShellNew
22 - C:\WINDOWS\All Users\Start Menu
23 - C:\WINDOWS\All Users\Start Menu\Programs
24 - C:\WINDOWS\All Users\Start Menu\Programs\StartUp
25 - C:\WINDOWS\All Users\Desktop
26 - C:\WINDOWS\Application Data
27 - C:\WINDOWS\PrintHood
28 - C:\WINDOWS\Local Settings\Application Data
32 - C:\WINDOWS\Temporary Internet Files
33 - C:\WINDOWS\Cookies
34 - C:\WINDOWS\History
35 - C:\WINDOWS\All Users\Application Data
36 - C:\WINDOWS
37 - C:\WINDOWS\SYSTEM
38 - C:\Program Files
39 - C:\Save Folder\My Pictures
43 - C:\Program Files\Common Files
46 - C:\WINDOWS\All Users\Documents
47 - C:\WINDOWS\All Users\Start Menu\Programs\Administrative Tools
48 - C:\WINDOWS\Start Menu\Programs\Administrative Tools

mayayana wrote:
Show quoteHide quoteHmmmmm, this might be the cause of confusion, here.  Now you have me wondering about
something as well.  The m_Enhanced variable doesn't signal Vista, at all.  It's just
saying that SHGetFolderPathA is available to use, which implies that we either have
IE5 or VPC Virtual Machine Additions installed.

   ' Make sure we have the function this class relies on!
   m_Enhanced = Exported("shfolder", "SHGetFolderPathA")

Now I'm wondering why I pulled that ForceCreation test inside just half the
operation.  It really oughta be moved up outside that If test, eh?  (Problem is, I
just don't operate enough -- read "at all" -- in a realm where the more enhanced
function isn't available, so my "graceful degradations" aren't always tested as
thoroughly as they really oughta be.)

Heh.

Show quoteHide quoteCould be they got some half-baked limits built right in?  Kind of like VB's native
SetAttr/GetAttr functions?  I really can't comprehend the reasoning, if you can call
it that, behind many of the self-imposed limitations Microsoft builds into things.
This seems to fit that same shortsighted methodology, though.  :-(

It's just
  Oh. I misread that. Or rather I really didn't read it.
I just somehow thought it was the new Vista version.
I guess because I thought I remembered you saying
recently that you don't like the shfolder.dll approach.

VB6 runtime is supported on Windows 7
ListBox color
Printing PictureBox Contents
FYI: MS UK VB6 Usage survey/poll - update
What am I doing wrong
Crash during compile
How to read XML data stream via a URL address into a string ?
Shared MS Fax
Problem getting the date of a running EXE file
Add objects already on form to Groupbox