async Leave callback for MUI page causing evilness

I have a verification function as a callback when you leave the Components Page, i.e.:

!define MUI_PAGE_CUSTOMFUNCTION_LEAVE verifyComponentReqs

!insertmacro MUI_PAGE_COMPONENTS

Unfortunately during this process you can still click on the Components Page. You can select/deselect components, click install again, which can lead to corrupt installer messages and installer crashes.

I display a banner in the method, but it takes 1-2 seconds to load the DLL so you can still click on the buttons. I disable the Install button, but you can still select components. Is there a way to lock the dialog? I have a few ideas on workarounds:

A) Load the banner DLL earlier. Is there a way to load a plugin DLL explicitly without calling a plugin function? I suppose I can do "Banner::destroy /NOUNLOAD" but that seem really hacky.

B) Use the next page's PRE callback instead, and then go back to the Components Page if the conditions aren't met. But this isn't ideal from a usability standpoint because it will seem to the user that they're already in the install progress, which they're not.

I'd appreciate any suggestions/corrections.

Thanks,
bobics

why not just disable the component list aswell?

I cannot reproduce this. Please attach a complete example.

As for loading the Banner faster, it's probably due to the solid compression. Simply ReserveFile it on the top of the script.

I spent some time stripping down my installer and discovered that it has something to do with the FindProcDLL I'm using, http://nsis.sourceforge.net/FindProcDLL_plug-in (although it may not be *specific* to that DLL). If you double-click on "install" very quickly, you should see the error. I've included the repro script below, and attached a screenshot of the error.

SetCompressor /solid lzma



;---- MUI ------------------

!include "MUI.nsh"



; Component selection page

!define MUI_PAGE_CUSTOMFUNCTION_LEAVE verifyComponentReqs

!insertmacro MUI_PAGE_COMPONENTS

; Instfiles page

!insertmacro MUI_PAGE_INSTFILES



;--- Project Settings --------

OutFile "Stripped_Installer.exe"



Section

	SetOutPath "C:\test_comp_page_click"

	SetOverwrite on

	File /r "C:\Program Files\NSIS\*"

SectionEnd



Function verifyComponentReqs

	FindProcDLL::FindProc "does_not_exist.exe"

FunctionEnd

I still can't reproduce. Which version of NSIS are you using?

NSIS 2.28 - I am using several other plugins (but as I understand it, they won't be include if they aren't used).

Otherwise the only file that's different from a stock install is the Banner.dll (due to the banner hanging bug, forums.winamp.com/showthread.php?s=&threadid=270838&highlight=banner)

You have to double-click very quickly in this sample... perhaps your computer is too fast? 🙂 In my production script you can wait a few seconds before the second click and still see the error.

Anders - thanks for you suggestion. In case anyone else might find it useful, I used the following:

FindWindow $1 "#32770" "" $HWNDPARENT

FindWindow $1 "SysTreeView32" "" $1

EnableWindow $1 0

kichik - Since I'm using the above workaround, I think our installer is okay for now but it's still probably better to figure out why the dialog is not blocking. Would it help if I performed a clean install of NSIS and try to repro?

Please attach your script.

Stu

Hi Stu - I pasted the script in its entirety above, but here it is again as an attachment.

Thanks - Andy

Not that one 😁
I mean your actual script because we cannot reproduce the problem with that one.

Stu

Unfortunately I don't think my company would allow me to post my script in it's entirety... what I can do is try to come up with a more reproducible case. I'll post again when I do. Also if it helps I can make available a compiled setup.

Thanks, fixed. The decompression function messed with the message loop when it shouldn't have.

Thanks for the fix and update!

Hmm, I just added a custom dialog using nsDialogs.nsh and I saw the same type of installer crash when clicking on the "Next" button really quickly twice. So I think this bug still exists.

I'm using the same workaround of disabling the next button in the leave callback of the custom dialog.

I can't reproduce. I'll need an example again.