Get "Program FIles" folder location

[bakerm]

What is the easiest way to get the location for the "Program Files Folder"?

Typically it will be located at C:\Program Files, but not always in our environment.

Is there a functionality similar to the GetWindowsDirectory API that will give me this information?

Thanks for any help you can offer!

 

[bakerm]

I did manage to get this to work:

Set WshShell = CreateObject("WScript.Shell")
Set WshSysEnv = WshShell.Environment("PROCESS")
AllUsersProfile = WshSysEnv("PROGRAMFILES")

Any better suggestions?

 

[SBerthold]

Do an Exact Phrase search in this forum using:
Shell32.Shell

Once you add a reference to the Shell32 in your project, you can look at all of the other folder contsants in the object browser (F2)

 

[strongm]

My GetSpecialFolder function in my second post in thread222-573084 is one alternative.

 

[SBerthold]

strongm,
I noticed you wrote in the thread code

>If you have shell32.dll version 5.0 or later (XP, W2000, Windows Me) you MUST use the following instead:

Just curious, as you surely have your reasons:
Why "MUST"?

 

[strongm]

It is more that you can't use the 4.71 method shown, since it fails under 5.0

And it can fail because (obscure Microsoft documentation states):

Not all methods are implemented for all folders. For example, the ParseName method is not implemented for the Control Panel folder (CSIDL_CONTROLS). If you attempt to call an unimplemented method, a 0x800A01BD (decimal 445) error is raised

The v5 method is cleaner anyway.

 

[SBerthold]

Thank you.
I thought it must have been something I am not using yet (no query used on the new folders). Therefore it still works for me.

 

[dilettante]

Hmm, I've been using a semi-documented feature that seems to work fine. I've only tested it on 5.x platforms but it looks as if it should work downlevel too:

Option Explicit
'
'Requires reference to Microsoft Shell Controls and Automation.
'

Function GetSpecialPath( _
    ByVal ssfDir As ShellSpecialFolderConstants) As String

    With New Shell32.Shell
        GetSpecialPath = .NameSpace(ssfDir).Items.Item.Path
    End With
End Function

Sub Main()
    MsgBox GetSpecialPath(ssfPROGRAMFILES)
End Sub

The key point here is the optional index parameter of the Item() method of the FolderItems object. Leaving this out of the call does not substitute an index of 0 as one might expect. Instead it returns the Folderitem of the parent Folder object.

Is this flawed? Has anyone tested it on a 4.71 machine?

 

[strongm]

Try passing it ssfDESKTOP ...

 

[SBerthold]

I mentioned that I had verified what was missing under the older methods, and I thought the results may interest someone:

From strongm's post in thread222-573084 for the shell 4.71 method, these are the items which do not work on systems with Shell 5+:
ssfDESKTOP
ssfCONTROLS
ssfPRINTERS
ssfBITBUCKET
ssfDRIVES
ssfNETWORK
ssfALTSTARTUP
ssfCOMMONALTSTARTUP





For the above method posted by dilettante, the folders which do not work with Shell 5+:
ssfDESKTOP
ssfALTSTARTUP
ssfCOMMONALTSTARTUP

And for the shell 5.0 method in thread222-573084, this one item doesn't work:
ssfCOMMONALTSTARTUP

All items listed are Virtual Folders except ssfALTSTARTUP and ssfCOMMONALTSTARTUP.


Also, one Virtual folder not listed in the ShellSpecialFolderConstants is 0x1
::{871C5380-42A0-1069-A2EA-08002B30309D}
(IE icon?)

http://msdn2.microsoft.com/en-us/library/ms630424.aspx

 

[dilettante]

Yes, there are a lot of limitations.

With the move to Vista I've found a need for ssfCOMMONDOCUMENTS, which doesn't exist but if defined (&H2E) works on some systems and not others. I've pretty much given up on the Shell Controls and Automation components and gone with a wrapper on the API calls to Shell32.dll where CSIDL_COMMON_DOCUMENTS works fine.

Even then there are limitations depending on which entrypoints you're using, but it's all pretty well documented. vDirs like ssfDESKTOP are virtual folders and not filesystem locations, so you have to take a somewhat different route anyway and soon you're messing with IMalloc.