SetShellVarContext all --> $DOCUMENTS

SetShellVarContext all

MessageBox MB_OK $DOCUMENTS

This still shows the path to my local user documents and not to all users documents...

Why? I'm working on Windows XP SP2, so this should work, as all users folder does exist...

Lieven

Strange, I am also getting the same ...
CF

works for me (XP SP2 MCE2k5)

Well, apparently it is not to be trusted...

Any word on this? I'm experiencing the same problem.
All the PCs I'm testing this on are Windows XP SP2.

I created a sample install and all it does is:
SetShellVarContext all
DetailPrint "All DOCUMENTS: $DOCUMENTS"

SetShellVarContext current
DetailPrint "Current DOCUMENTS: $DOCUMENTS"

On some PC it behaves correctly but on others this is what I get:
All DOCUMENTS: C:\Documents and Settings\jcolon\My Documents
Current DOCUMENTS: C:\Documents and Settings\jcolon\My Documents
Completed

I cant seem to figure out what's different between all these PCs. I'll keep checking and post back if I find anything.

jc3

I have tried your example code, and it dosen't seem to work. I have tried it with $DESKTOP, $VIDEOS, $MUSIC, and $PICTURES, and these all work. Could be a bug that has not been fixed (or windows has changed the way the 'My Documents' folder is stored 🙁).

hmm... mine works fine. I have XP pro SP2.

Out of curiosity, on those machines that have the problem,
what version of Windows XP is being used? (Home, pro, media edition, 64-bit, etc.)

And when you're in windows Explorer, do you have a 'shared documents' folder? If so, I presume that takes you to the 'all users' folder (ie C:\documents and settings\all users\documents)?

[edit]
I found this blog that talks about problems with the 'shared documents' folder:
http://blogs.msdn.com/jmazner/archiv...29/363160.aspx

And this article about how to disable the 'shared documents' folder by editing the registry:


(Just thinking that if maybe the shared documents folder has been disabled, you can reverse to 're-enable' it.)

That just removes them from "my computer". BTW I'm running as a restricted user and it still works

I have XP Pro SP1 x86(haven't tried it yet) at home and the college computers are XP Pro SP2 x86.

I will look into it as soon as possible, but I still think it is a bug in nsis. Workarounds are an option, but not a solution.

What's strange is about half the PCs I've tried exhibit the problem (Mine is one of them), and the other half behave correctly.

Also, as JasonFriday13 stated the $Documents variable seems to be the only one behaving oddly - even on my machine (which has the problem) the other variables behave correctly. As someone else suggested it may be a problem with just $Documents.

And also, Comperio asked about the exact version Windows I was testing with. I work for a software firm and we are all Dell (Intel x86) with Windows XP Pro SP2. I still have to look at the blog info you have provided and do more digging.

Finally, I created both a standard User account and a standard Admin account when testing and it didn't make a differenct so I think we can rule out permissions.

I'll keep looking...

Works fine for me as well. Windows XP Pro SP2.
Just tried it on NSIS v2.15 and then installed v2.17 and it still works.

-Stu

I am buffled. I am also using XP Pro SP2. Both calls get the value from HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders\Personal (using NSIS 2.17) ...
CF

I just tried it with NoSharedDocuments=1 and it does seem to disable the common folder since I get my local one

Just an FYI, I have checked, none of the PC have the registry setting set (both work and non-working).

jc3

Okay, I had a theory I just tested. The only thing I noticed that was different between the "work" PCs and the "Non-Working" PCs was the "Non-Working" PCs are part of a Windows Domain. All the "Working" PCs were never added.

Now what I don't know and I need to find out is if this is Windows policy related or default behavior. I don't think we use Windows policies (or very little) but I'll find out if and which - if we are using them.

For those of you who have chimed in can you report whether or not you are part of a Domain or not?

I'll keep digging...

Thanks.

jc3

The two XP SP2 (One is MCE2k5 and one is Pro) computers I tested on are not in a domain

No domain here, just a workgroup.

-Stu

I am not in a domain either but it is not working 🙁
CF

but do you have NoSharedDocuments=1 (in HKCU or HKLM)

Good point Anders!

For me it is the HKLM value of NoSharedDocuments that makes the difference 🙂

If it is set to 1 then I can only see the user's $DOCUMENTS regardless of the SetShellVarContext value

CF

Just to reiterate, we do not have NoSharedDocuments set at all.

Could a Dev. chime in please?

Thanks.

jc3

This might be of help:



If this part of NSIS is not working for you, the best would be to enter a defect in the defecttracker(bug)

and then focus on what you want to achieve and not use the $DOCUMENTS var but make you own routine via the system module.

After all it handy to use default values but not obliged, and if it does not work one better finds an alternative for himself thad does.

I'm sad to say but creating installer and programming just IS a lot of work once in a while...

Thanks for the info link Onad. I wasn't aware of the defecttracker so I will enter a bug.

jc3

Here's my Win32 API workaround for those who may be interested:

Function GetSharedDocPath
# Win32 API documentation:
# Call: http://msdn.microsoft.com/library/de...folderpath.asp
# Enum: http://msdn.microsoft.com/library/de...nums/csidl.asp

SetPluginUnload alwaysoff
StrCpy $1 ""
IntOp $2 0x002e + # CSIDL_COMMON_DOCUMENTS (0x002e)

System::Call 'shell32::SHGetSpecialFolderPath(i $HWNDPARENT, t .r1, i r2, i r3) i .r4'

SetPluginUnload manual
System::Free 0

DetailPrint "API Call Results: $1"
FunctionEnd

[edit]new links

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

The Enum is:
http://msdn.microsoft.com/en-us/library/bb762494(VS.85).aspx
[/edit]

I have made a wiki page here using JeronimoColon's NSIS example, just so people can use it for future reference.

Seems to be related to http://sourceforge.net/tracker/index...49&atid=373085

Nsis uses SHGetSpecialFolderLocation since SHGetSpecialFolderPath needs shell v4.7(IE4 desktop update)

Maybe nsis should check and use SHGetSpecialFolderPath if it is available on the system

I have just tried SetShellVarContext all at home on my XP pro SP1 x86 machine, and it works just fine.

Seems like a bug in SHGetSpecialFolderPath that the workaround uses rather than a bug in SHGetSpecialFolderLocation which NSIS uses. If a policy in the domain or on the local computer disables the shared documents folder, it shouldn't be accessed. The fact that it still exists doesn't mean it's used.

As for $DOCUMENTS getting the user's path, that's just how every variable works. If the folder for all users can't be found, the current user's folder is used. This way, there should never be an empty shell variable unless it really doesn't exist.

After some quick testing, it seems like only $DOCUMENTS is affected, $PICTURES and the other folders inside my documents still resolve to the all users path

curr $DOCUMENTS: C:\Documents and Settings\Anders\Documents

all  $DOCUMENTS: C:\Documents and Settings\Anders\Documents

curr $PICTURES: C:\Documents and Settings\Anders\Documents\Pictures

all  $PICTURES: C:\Documents and Settings\All Users\Documents\My Pictures

curr $MUSIC: C:\Documents and Settings\Anders\Documents\Music

all  $MUSIC: C:\Documents and Settings\All Users\Documents\My Music

curr $VIDEOS: C:\Documents and Settings\Anders\Documents\Videos

all  $VIDEOS: C:\Documents and Settings\All Users\Documents\My Videos

curr $DESKTOP: C:\Documents and Settings\Anders\Desktop

all  $DESKTOP: C:\Documents and Settings\All Users\Desktop

curr $APPDATA: C:\Documents and Settings\Anders\Application Data

all  $APPDATA: C:\Documents and Settings\All Users\Application Data

curr $TEMPLATES: C:\Documents and Settings\Anders\Templates

all  $TEMPLATES: C:\Documents and Settings\All Users\Templates

curr $STARTMENU: C:\Documents and Settings\Anders\Start Menu

all  $STARTMENU: C:\Documents and Settings\All Users\Start Menu