1

I am trying to use ShGetFolderPath to determine the path of the user profiles folder. The documentation states that CSIDL_PROFILES defines this folder:

CSIDL_PROFILES (0x003e)

Version 6.0. The file system directory containing user profile folders. A typical path is C:\Documents and Settings.

I am using Visual Studio 2005 SP1, and I cannot locate the definition of the constant CSIDL_PROFILES in the Platform SDK include files? Do I need a new version of the Platform SDK?

So I did some more experimenting by using the ID 0x3e in place of the symbol. However, it looks like 0x3e is not a valid argument to the shell functions that accept CSIDL_* arguments (an invalid argument error is returned).

So I guess CSIDL_PROFILES is not a valid argument and the at least some of the MSDN pages on the subject are incorrect when they mention this symbol. I have to say in all my years of working with the Win32/MSDN documentation I can't remember a similar situation.

Remy Lebeau
  • 555,201
  • 31
  • 458
  • 770
jmatthias
  • 7,375
  • 7
  • 27
  • 36
  • Can you give a link to an MSDN page referring to CSIDL_PROFILES? I couldn't find one... – Roddy Jun 26 '09 at 09:33
  • @Roddy, I cannot find it at msdn.com, the reference I found was in the local MSDN help that ships with VS2005; ms-help://MS.VSCC.v80/MS.MSDN.v80/MS.WIN32COM.v10.en/shellcc/platform/shell/reference/enums/csidl.htm – jmatthias Jun 26 '09 at 15:08

3 Answers3

0

It's not listed in the MSDN documentation for CSIDLs, so a newer version of the PSDK is unlikely to help you.

You can obviously do it yourself:

#define CSIDL_PROFILES 0x003E

... but in view of the fact that it appears totally undocumented by MS, it's not something I'd recommend.

Roddy
  • 66,617
  • 42
  • 165
  • 277
  • 1
    It's strange that it appears in one version of the MSDN page (the one that ships with VS2005). It's as if they have removed it. I did try to use the ID directly but that does not appear to works since the shell functions return an invalid argument code when I use 0x3e. – jmatthias Jun 26 '09 at 01:49
0

I'd say this was removed when someone noticed that it's worthless. Waht can you do with it anyway? You still have to determine for each user whether his profile actually exists under this directory. But since you're normally checking this per user, the only point when you need the default is when you're creating a new user profile. And that's Windows-internal code anyway.

MSalters
  • 173,980
  • 10
  • 155
  • 350
  • In my case, it would have been useful. I actually did need to know the location of this folder because I needed to iterate through all user profile folders and copy a file to each 'SendTo' folder. Bear in mind that this code was run during an installation running with Admin rights. In the end I had to read the current user profile folder and determine the parent folder. – jmatthias Jun 29 '09 at 15:25
  • 1
    No, that's indeed a good example why it's wrong. The proper solution is to iterate over all users and then retrieve for each user their profile folder. Your solution fails if the computer has a mix of roaming and non-roaming profiles. – MSalters Jun 30 '09 at 07:16
0

You should be using GetProfilesDirectory() but if what you really want is the CSIDL of a different user you should call SHGetFolderPath with their token. (If you don't have their token you need to use a hacky workaround)

Community
  • 1
  • 1
Anders
  • 97,548
  • 12
  • 110
  • 164