Re-read updated registry value

[hackingbear]

Hi,

I'm attempting to do following:

1. Read a registry value into $R0 (J2SDK installed path)
2. If not set, run the external program (J2SDK installer)
3. Read the same registry value set by the external program into $R0
4. If not set, abort
5. continue

I found that the second read does not return me the new value set by the external program. I couldn't find anything that allows me to resync the registry. Did I do something wrong?

Thanks.
-HB

[Sunjammer]

Hmmm I guess Windows could be caching writes to the registry, in fact the presence of a Windows API called RegFlushKey() makes me believe that even more. I doubt there is a way to sync the entire registry since that would be very costly, I guess you could try using the System plugin to invoke RegFlushKey (and yes it does work on the major branches of the registry, e.g. HKLM or HKCU).

Microsoft MSDN informationa about RegFlushKey can be found here.

[kichik]

I would first check if you have used Exec or ExecWait to execute the other installer. ExecWait will wait for the installer to finish while Exec will continue right on without waiting. If you have used ExecWait make sure it really does wait. Some installers extract a temporary executable and call it and return immediately which makes NSIS think that the program has finished, which is of course not true. If this is the case see this thread. If your installer does wait as required use Sunjammer's solution.

[psyke]

any more info on this hackingbear? (or anyone else )

was it an exec vs/ execwait issue as kichik indicated, or was a registry flush required?

i'm just curious since i often write a registry key and then read it later on with no problems (at least i haven't become aware of any errors - lol).

I have even manipulated a key in an installer, changed the same registry key from another program and then read the updated value into the installer with nor problems without doing a registry flush.

I'm concerned becaused Sunjammer's approach makes sense to me and appers to be a very safe way to do what I'm doing, but i'd really rather not revise my installer script unless this flushing is really necessary. :P

Cheers.

[faetter]

I have kind of the same problem as hackingbear. Although registry values are changed by en external program the NSIS uninstaller still reads the old values.

Here's what's in my Uninstall section:
1. Call my application with a command line parameter to remove registry entries.
2. My application's files are removed.
3. NSIS removes it's registry entries.

The removal of reg. entries in step 1 is quite complicated so the easiest way to do it is simply to call my application .

The funny thing is, that if I make my app show a messagebox and thereby pausing its execution and then check the reg.values in regedit, they have updated correctly. But when my app has exited and the uninstaller is at step 2 the old values magically has returned.

I have checked and ExecWait correctly waits till my app has exited. I have even made the uninstaller Sleep 10000 msecs (after ExecWait has executed) and that doesn't change anything. I call the Windows API's RegFlushKey() from my app but it does not change a thing...

This is strange me thinks!

[Takhir]

faetter:
The only situation I can imagine is that registry values still remain in HKLM, so if you removed HKCU values, Window substitutes HKLM ones.

RegFlushKey() - this call may flush current open reg. key or section (HKLM), but do this (I guess, because who knows how MS lazy flusher was done) for current process only and not touches another process ( Java SDK installation). But this is still very strange, good idea is to test installation on few platforms - W2K, XP, W98 (and W95 Gold

[faetter]

The only situation I can imagine is that registry values still remain in HKLM, so if you removed HKCU values, Window substitutes HKLM ones.

The registry entries that my application removes are located in HKEY_CLASSES_ROOT so it is probably not the issue.

That RegFlushKey() is so badly coded that it only flushes for the current proces sounds so unbelievable that I'm willing to believe you!

Arrgh, I must find some other smart way to do it then i guess... Suddently everything gets sooo complicated and silly me who though I could do things the easy way -sigh-.

Btw. I'm using XP Pro.

[faetter]

Hmmm... maybe I could work around it by doing this:

1. When you click the Uninstall icon in the Start Menu it launches "MyApplication.exe -uninstall".
2. My application is then launced and removes the registry entries.
3. When done, my app will terminate itself and make the NSIS uninstaller run right after (can this be done??).

What do you think?

[Takhir]

and in some other situations. But you know all file names, so it is easy to add a part of uninstall code to your application and run uninstaller (using WinExec() for example).

[faetter]

It will not be a big problem but it is not very nice I know .

The problem is that my application must not run while NSIS is uninstalling it. Have you got an idea on how to accomplish that?

I looked at WinExec() but wont it require that my app is running at the same time as NSIS?

[faetter]

I looked at WinExec() but wont it require that my app is running at the same time as NSIS?

No it wont - I'll try WinExec()