ghennessey
15th November 2008 21:05 UTC

EnvVarUpdate.nsh and WM_WININICHANGE timeout
The following line of code in EnvVarUpdate.nsh hangs up my installer until the timeout is hit:

SendMessage ${HWND_BROADCAST} ${WM_WININICHANGE} 0 "STR:Environment" /TIMEOUT=5000

If I comment this line out, everything seems to work fine, and there is no delay - I suspect this is for older operating systems. I'm working on a Windows 2003 server (the installer is for server software). I'm using NSIS 2.40.

Can this line be safely removed, or is there some fix?

I'm calling the function using:

${EnvVarUpdate} $0 "PATH" "A" "HKLM" "$INSTDIR\lib"

Thanks,

Geoff.

kichik
15th November 2008 21:24 UTC

If you remove it, changes will only take effect after reboot.

ghennessey
15th November 2008 21:39 UTC

Thanks for the quick reply.

The changes seem to take without a reboot on Server 2003 - at least when I go to 'Control Panel - System' and look at the environment variables it's there after running the installer.

WM_WININICHANGE seems to have been retired in newer Windows systems:

http://msdn.microsoft.com/en-us/library/ms725499.aspx

I tried sending a WM_SETTINGCHANGE instead and it didn't hang up, although I'm not sure how to verify if it's working, as the change takes regardless. I'm not sure about my syntax either:

SendMessage ${HWND_BROADCAST} ${WM_SETTINGCHANGE} 0 "STR:Environment" /TIMEOUT=5000

Is there a way in NSIS to tell which operating system is in use, and filter the message appropriately?

Thanks,

Geoff.

kichik
15th November 2008 21:55 UTC

The changes will appear in the control panel but if you open up a new command shell and test it you should see it won't take effect until you reboot or use the control panel to apply the change.

ghennessey
15th November 2008 22:12 UTC

Yes, you're right, the changes don't show up properly when I open a new command shell.

WM_SETTINGCHANGE also doesn't solve the problem after all, in that it still hangs up. It seemed to be working initially, but it's not anymore. I must have made a mistake and not saved the included file.

If I reduce the timeout to 250, the wait is much shorter, and the changes take - they show up in a new command prompt window. Do you know what the timeout is waiting for?

Thanks,

Geoff.

kichik
15th November 2008 22:15 UTC

The timeout is waiting for one of the programs in your system which is not responding. It might be busy or it might have some sort of a bug preventing it from responding in time.

ghennessey
15th November 2008 22:37 UTC

That was it exactly - there was an unresponsive IEXPLORE.EXE running in the background. After rebooting, no problem with the installer hanging up.

Is a /TIMEOUT=0 valid? Basically to say, I don't care if all the programs respond to the change, just send the message and move on? I tried it and it seems to work - a new command prompt window reflects the change.

Thanks,

Geoff.

kichik
15th November 2008 23:06 UTC

/TIMEOUT=0 is invalid and will act exactly as a normal SendMessage and this means completely synchronous. That means if you get a non responding program, there will be no timeout. If you don't mind for non responding programs, use a very small timeout, but not 0.

ghennessey
15th November 2008 23:37 UTC

Good to know! Thanks for all your help today, it's been invaluable.

Geoff.