Announcement

**Michael Mattias** · 29 Mar 2009, 10:02 AM

>Am I Doing Get Special Folders Right>

Not really.

You need to interrogate the return from ShGetSpecialFolderPath.

Code:

  iRet = ShGetSpecialFolderPath  (params) 
  IF ISTRUE iRet THEN 
     ' call succeeded, so now you can parse out the return data buffer
  ELSE
    ' call failed
     LE = GetLastError()     ' get Windows error code for the error.
     FormatMessage.....    ' get text of Windows error for display 
 .....

PB's ERR system variable does not return any data for direct calls to Windows API functions, that is, the ON ERROR in your code will never be executed because the call failed, although it could be executed because one of the PB verbs failed.

Here's some code which may or may not be useful...
Move That INI File! and Get That Ini File Name!

MCM

**Michael Mattias** · 29 Mar 2009, 11:55 AM

>Want to ensure that this works across all platforms...

If you mean using the WinAPI calls with the %CSIDL_xxxx constants to locate special folders, it does, at least on systems from Win/98 thru Vista/32. I don't have any clients on Win/95 or Vista/64 so I can't speak to those.

**colin glenn** · 29 Mar 2009, 01:27 PM

Looking at the documentation and the examples, I really don't need to try the SHGetSpecialFolderPath at all it seems. And considering that I'm wanting to put my ini file in an existing %CSIDL_LOCAL_APPDATA folder, I really don't need all the extensive testing and creation code either. Thanks for the tip.

**Michael Mattias** · 29 Mar 2009, 02:20 PM

really don't need to try the SHGetSpecialFolderPath at all it seems. And considering that I'm wanting to put my ini file in an existing %CSIDL_LOCAL_APPDATA folder, I

????

If you want to put your data in CSIDL_LOCAL_APPDATA, you need to use "some" system call to get the name of that folder, unless you hard-code it for a specific system.

Real Men don't hardcode special folder names, they use CSIDL_* equates and one of the system API functions to get the name.

Note also, those folders ARE user-moveable (But I have never seen that actually done).

I really don't need all the extensive testing and creation code either. Thanks for the tip.

What extensive testing and creation? It's a one-line call to "GetIniFileName" (post #2) after you set your equates.

MCM

**colin glenn** · 29 Mar 2009, 10:19 PM

I'm sorry Michael, I am saying all that really wrong, what I mean is that all I needed was this as a matter of fact:

Code:

    iRet = ShGetFolderPath (BYVAL %NULL, _             ' hWnd, "typically null"
                            %CSIDL_LOCAL_APPDATA, _    ' (supported) CSIDL value
                            BYVAL %NULL, _             ' hToken for security, null  = Default
                            BYVAL 0, _                 ' above
                            szBaseFolder)

Some times I don't explain the reasoning why, but the deal is that I'm writing, (or rather porting from VB), a file editor for an online game. If you don't have the game installed, there's not much sense in using the editor. After getting the back this particular folder, I tack on a specific path and check for the presence of the game's data folder, and if it's not there, not much sense in going further because my editor's fairly useless without the game data files.

BTW: Why break down the folder path to be created when you can use SHCreateDirectoryEx to create the whole thing in one action?

**Michael Mattias** · 30 Mar 2009, 08:41 AM

What I was trying to point out was that your original test...

Code:

 IF INSTR(SpecialPath, $NUL) > 1 THEN

... is not the correct test for the success or failure of the call to ShGetSpecialFolderPath. The correct test is the value of the function's return value.

After that succeeds, you can parse out or modify or do whatever you want with the data now in the variable 'SpecialPath.'

MCM

**colin glenn** · 30 Mar 2009, 02:48 PM

I realize that now, forgive me with some strange quirks from the code, a lot of it is cut and paste from one of 2 VB projects which contain a lot of strange eXtreme coding actions to make the API call work in VB. The prefix for that particular line was preloading the return string with String$(MaxPath, 0), ...

**Michael Mattias** · 30 Mar 2009, 05:05 PM

It would have been the wrong test in VB, too.

Just as a general rule.....

When a WinAPI function returns failure, you cannot use the contents of any variable that function would have filled had it succeeded.

MCM

Announcement

Am I Doing Get Special Folders Right?

Am I Doing Get Special Folders Right?

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment