timbuck
19th August 2005 13:31 UTC

$DOCUMENTS does not change to Shared Documents with SetShellVarContext
Hi there, I've tried to find the answer on this website with no luck, although I am pretty sure someone else must have seen this. :)

I want to install some files to the 'shared documents' folder.

The documentation says...

$DOCUMENTS

The documents directory. A typical path for the current user is C:\Documents and Settings\Foo\My Documents. The context of this constant (All Users or Current user) depends on the SetShellVarContext setting. The default is the current user.

But if I compile the following script and run it on NT4 or XP PRO I only get the users documents folder. Strangely it works on XP Home.

Name "Test"
OutFile "Setup.exe"

Function .onInit
   MessageBox MB_OK "$DOCUMENTS"
   MessageBox MB_OK "$SMPROGRAMS"

   SetShellVarContext "all"
   MessageBox MB_OK "$DOCUMENTS"
   MessageBox MB_OK "$SMPROGRAMS"
FunctionEnd

Section "default"
SectionEnd

(I should add that $SMPROGRAMS functions correctly, but not $DOCUMENTS)

Does anyone know why this is, or is there a suggested workaround?

From a C++ windows API point of view the Shared Documents file does exist on these systems and is retrieved by a call to SHGetSpecialFolderPath(...) so I am not sure why $DOCUMENTS would differ from this.

I'd just like to add that I really have preffered NSIS over other certain offerings that do a lot of (irritating) things by default and you spend ages trying to turn it all off. NSIS on the other hand just does what you tell it to. Nice. ;)

timbuck
19th August 2005 14:06 UTC

Well... I've had to come up with a workaround that uses a new method in our plugin dll (taken from the example exdll).

I'd still like to know if I could avoid it though!

Here is the workaround

C++:

void __declspec(dllexport) GetSharedFolderLocation
   (
   HWND hwndParent,          // 
   int string_size,          // 
   char *variables,          // 
   stack_t **stacktop,       // 
   extra_parameters *extra   // 
   ) 
{
   g_hwndParent=hwndParent;
   
   EXDLL_INIT();
 
   // do your stuff here
   {
      // Get the Shared Folder
      // get path of Shared Documents
      char sharedDocsPath[MAX_PATH];
      SHGetSpecialFolderPath(NULL, sharedDocsPath, CSIDL_COMMON_DOCUMENTS, 0);
      pushstring( sharedDocsPath );
   }
}

NSIS:

   utils::GetSharedFolderLocation
   Pop $0
   MessageBox MB_OK "$0"

kichik
19th August 2005 16:19 UTC

$DOCUMENTS is implanted using SHGetSpecialFolderLocation with CSIDL_COMMON_DOCUMENTS, which should be no different. I have no idea why it should work differently at all, and specifically on different versions of XP. We can not use SHGetSpecialFolderPath because it's not available on all supported versions of Windows.

timbuck
19th August 2005 21:34 UTC

Hi, thanks for your reply!

That IS strange, I am going to do a little test and I'll post the results on monday when I can get to the other machines.

Apparently a quick read suggests SHGetFolderPath superceded both of our functions with Win 2000/ME and it looks like it exists in both Shfolder.dll and Shell32.dll depending on what you link with I think. I wonder if one function is linking into one and the other into the other?

Thankfully, I am ok to call this function during the installation because we install the shfolder.dll redistributable (shfolder.exe) before we call it.

Anyway, I'll let you know what the other Shell functions are returning on these machines when I get back in to work!

(I am probably unlucky and our systems dept have our machines setup weirdly! We'll see.)

timbuck
19th August 2005 21:38 UTC

Just thought, I hadn't installed the ShFolder.dll on the NT box before running the test, which may explain it's behavior, but that still leaves me with the XP Pro/Home mystery.