ExecWait issue - NSIS Forums

Pravin
13th October 2010 12:17 UTC

ExecWait issue
Im new to NSIS and following is my issue.

Im having two different path directory for client and server so im using custom variables to save the path instead of $INSTDIR.

while installation im checking whether any previous version exists and if exists im calling uninstaller to uninstall using ExecWait as follows.

ExecWait '$G4 _?=$INSTDIR'

Steps :
-------

1.exe executed.
2.prev version found.
3.uninstaller is triggered.
4.installer is disabled and uninstaller is active.
5.i shifted my focus to installer and clicked "NEXT" . Result : NO change in the installer since it is disabled.
6.i proceeded with uninstallation.
7.After Uninstallation , Installer becomes active.
8.I found installer has skipped one page since i clicked "NEXT" when it was disabled.

why does the page is being skipped? How to avoid it??

I tried searching for this issue in forum but couldnt find. if the issue is addressed already let me know the link. else please help me to find a solution. Thanks in advance.

Yathosho
13th October 2010 13:08 UTC

not sure why this is happening, but you could disable the next button for the time the uninstaller is active.

you can actually copy&paste the first two lines of given example.. (next=1, cancel=2, back=3)

Pravin
13th October 2010 14:13 UTC

Thanks for the response. im not able to understand which example your are talking about. could u give me the sample code to disable the next button. thanks once again.

vankaa
13th October 2010 15:02 UTC

Click his "disable" and you can read what you need.

GetDlgItem $0 $HWNDPARENT 1 <---- 1-next
EnableWindow $0 0

Pravin
13th October 2010 18:00 UTC

thanks Yathosho and Vankaa for the respose.

The code disabled NEXT button. but still if i click on it, after uninstallation once it enters back to the installation i find it skips pages according to total number of clicks on NEXT (disabled) button.

some one do me a favour. using MUI create a sample nsi in which u call another installer and try clicking on the NEXT button when the installer is not in active mode and let me know whether u too face the same issue. Thanks in advance

Afrow UK
13th October 2010 18:09 UTC

Please submit a bug report. For now, try using a Banner (see NSIS\Docs). You could also try putting some Sleep statements after as well.

Stu

Netsurfer24
14th October 2010 13:32 UTC

Originally posted by Afrow UK
Please submit a bug report.

I don't think that it is a bug. I guess it has more to do with the fact that the mouse clicks are being "queued" during the ExecWait. And as the button is re-enabled afterwards the previous clicks are now being processed.

Originally posted by Pravin
The code disabled NEXT button. but still if i click on it, after uninstallation once it enters back to the installation i find it skips pages according to total number of clicks on NEXT (disabled) button.

Yes, see above for the possible reason.

I am doing quite the same (uninstall previous version during install) as you do. IMO you have a fault in your concept. Calling the uninstaller directly from one of the installer pages is generally a bad idea. What if the user cancel the installation afterwards?

I added a separate topmost hidden section from where I call the uninstaller (if needed). You can control this e.g. by using

SectionSetFlags${<name_of_your_section>} ${SF_SELECTED}

depending on a variable's value or whatever.

Good luck & success

Gunther

Afrow UK
14th October 2010 13:38 UTC

Originally posted by Netsurfer24
I don't think that it is a bug. I guess it has more to do with the fact that the mouse clicks are being "queued" during the ExecWait. And as the button is re-enabled afterwards the previous clicks are now being processed.

Yes that much is pretty obvious. I'd still regard this as a bug though because it is unexpected/undocumented behaviour.

Stu

Netsurfer24
14th October 2010 13:43 UTC

Originally posted by Afrow UK
I'd still regard this as a bug though because it is unexpected/undocumented behaviour.

Sorry, but I disagree. This is pretty much the normal Windows behaviour. It has nothing to do with NSIS.
If you want to change it you have to "manipulate" the mouse handling of Windows. But as I suggested, IMHO there is no need for this.

Gunther

Afrow UK
14th October 2010 13:53 UTC

This is not default Windows behaviour. I'm not sure how you got that idea. It will occur if you block the message thread for a window. In NSIS's case it still processes WM_PAINT but does not process anything else. It could be modified to process other window messages (thus eat them up) but not take any action.

Edit: However I definitely agree that use of ExecWait outside a section for long processes (and especially uninstallers) is definitely not a good idea.

Stu

Pravin
14th October 2010 14:06 UTC

Thanks Afro and Netsurfer for your suggestion. Thanks once again Afro for your active participation in the forum and for immediate response on the issues.

1. Just to confirm it is a BUG i asked others to check whether they too face the same issue
Do you face the same issue?? If yes , tell me the right procedure to report a BUG.

2. As discussed above that usage of ExecWait outside long processes is not good idea.
I'll make a note of it.

I have a situation where user need to uninstall the previous version before proceeding. I'll try to edit the current scenario.

Pravin
14th October 2010 14:09 UTC

Netsurfer i'll try to make utilize of the concept and the code given by you.Thanks.

SectionSetFlags ${<name_of_your_section>} ${SF_SELECTED}

Netsurfer24
14th October 2010 14:27 UTC

Stu,

Originally posted by Afrow UK
This is not default Windows behaviour. I'm not sure how you got that idea. It will occur if you block the message thread for a window. In NSIS's case it still processes WM_PAINT but does not process anything else. It could be modified to process other window messages (thus eat them up) but not take any action.

Hmmm ..., I thought it is the WM_NOTIFY Message which is responsible for the mouse clicks and as it is not disabled cause you disable a button in window ...
But I am pretty shure that you have a much deeper knowledge of these things than I have - so if you it is a bug then it is bug.

Originally posted by Pravin
I have a situation where user need to uninstall the previous version before proceeding. I'll try to edit the current scenario.

And the user may cancel/ abort the installation after this? What happened then - the user ends up with no installation at all? The previous one already uninstalled and the new one not installed?

At another place in my installer I solved this issue (don't want the user to click around) by hiding the whole installer window and only showing a banner during the process. Maybe this works for you, too?

Gunther

Pravin
14th October 2010 14:47 UTC

And the user may cancel/ abort the installation after this? What happened then - the user ends up with no installation at all? The previous one already uninstalled and the new one not installed?

By Netsurfer24

In uninstaller section i have a message box which will ask for the confirmation.
so only after confirmation it ll proceed to uninstall.

After that i check my registry


ReadRegStr $G4 ${PRODUCT_UNINST_ROOT_KEY} "${PRODUCT_UNINST_KEY}" "UninstallString"

>${if} $G4 != ''" 

>

if the registry is not null i assume it has not uninstalled and i call the same page by a goto condition to start of the page.

I know there must be some better way to call the page again like


 Call RelGotoPage 

>

. Im working on it :)

Pravin
14th October 2010 14:49 UTC

I have two radio button on the page

1.Add/Reinstall ( which will uninstall and proceed with installation )
2.Uninstall ( does only uninstallation )

Pravin
15th October 2010 08:29 UTC

Bug raised .Artifact ID: 3087924