Pomflain
25th January 2002 13:22 UTC

1.94 Installer/Uninstaller bug/crash
If you happen to set the installer or uninstaller to autoclose, and then do an ExecWait on something that can take a while and start up after the installer or uninstaller should have closed, then the program will hang and you must explicitly kill it.

I was made an uninstaller that then shells off the installer again since I was having the problem with the "uninstaller failed to initialize" with using ExecShell. So I switched to ExecWait, and that works fine. However, the uninstaller would appear behind the installer on some systems because of the latency between .onInit in the installer and the spawning of the uninstaller. So I changed it so that the installer writes it's location out to a REG_SZ and the uninstaller reads that and then tries to restart the installer just before it autocloses. The problem, however, was when I changed my ExecShell for the Hotsync.exe to an ExecWait. Hotsync.exe takes several seconds to load on any system since it scans the hardware ports and such, and it happened to launch after the uninstaller should have finished. The close button was greyed out, so I tried clicking on the 'x', but that didn't work. Nor did clicking on the left side and going to close, or alt-f4. So I'm using ExecShell again. The reason I wanted it to wait was because you could start to install the program again before the HotSync.exe restarted and that can lead to some less than perfect conditions.

So just pointing out this potential error...

rainwater
25th January 2002 16:40 UTC

Try using a Sleep xxx and a BringToFront command in the initialization of your uninstaller to bring it to the front.

Pomflain
25th January 2002 20:07 UTC

Been there, done that, doesn't work because that stuff is all done in .onInit so that the person doesn't pick options and then get punted from the installer. As such the window hasn't been put through the ShowWindow yet, and thus will appear on top of the installer on slower systems that take longer to get to that portion. I spent a few days trying combinations of bringtofront, and hidewindow with sleep commands and it doesn't work. What I have now works correctly, though, and doesn't depend on your system specs.

So thanks for the comment, but already tried that and it didn't work.

justin
25th January 2002 20:47 UTC

Hmm, I really don't understand what your problem is. Try to explain it more clearly, please.

-Justin

Pomflain
25th January 2002 21:01 UTC

Ok, you set the installer or uninstaller to autoclose. You then do an ExecWait on a program that times some time to load. In this case the Palm Desktop's HotSync Manager, which takes several seconds to load since it has to gather hardware information. So the installer or uninstaller finishes and would normally just close on it's own since the autoclose has been set. However, it doesn't close because of the ExecWait. The close button is greyed out, though, and you can't kill it through normal methods.

Does that help explain it better?

It's not a problem of any kind for what I'm doing, I wanted to see what would happen, and it wasn't the result I expected.

Pomflain
25th January 2002 21:10 UTC

I've been up too late...
Man, being up working the last 36 hours hasn't helped. I was thinking that it would return an exit code once the HotSync manager loaded correctly. However, it doesn't. I changed that line again and the uninstaller quit when I closed the HotSync. So I don't think there's a problem there. The StrCmp $x/ StrCmp "$x" thing, though, that's different...

justin
25th January 2002 21:56 UTC

Umm yeah, ExecWait waits for the child process to exit. You can use Exec if you don't want to wait.


StrCmp $x/StrCmp "$x"

huh?

-Justin

Pomflain
25th January 2002 22:24 UTC

I noticed that StrCmp $x str1 wasn't working like I figured. I was reading a REG_SZ from the registry and then doing StrCmp $var "" jump_equal. If the REG_SZ wasn't in the registry, then $var should be null, and always has been as far as I remember. Been using that bit in all the scripts for 5 ot 6 months. Anyway, I threw up a messagebox to make sure I was correctly reading the variable. Specifically it had to do with optional parts of the installer and how to handle an uninstall. If I installed this one optional part, then I was writing "Installed" into a registry key. That's what I was then reading back again and doing StrCmp $var on. Anyway, it was failing, so I changed it to the converse, so I made it StrCamp $var "Installed" jump_not_equal_from_before. I knew that the variable was exactly "Installed" since I was throwing it up in the messagebox. The StrCmp still failed, though. So I changed it to StrCmp "$var" jump... and then it worked.

I posted about this a few days ago but my post must have disappeared since it's nowhere to be found. I was just asking if this was the new behavior since the samples with the installed such as bigtest.nsi are using StrCmp $x "" and I was as well, but now it seems that StrCmp "$x" "" is needed to force it to a string. Thought maybe something with the internal string conversion might have gotten messed up. That's what I meant before.

Hopefully that makes sense...been up way too long at this point...