Archive: Can i use .onInstFailed for ignore button?


Can i use .onInstFailed for ignore button?
Hi

I have to change our Setup, but i don't know how can i do this. So i hope, anybody can help me.

While installing any files, a error occurred sometimes
( e.g. "file can't extract"). In the shown MessageBox is a "Ignore" button. Can i remove this 'ignore' button?

I would like to change the "Completed" Text, when any error messages occured while installing (4.8.1.10 CompletedText
). But how can i get the button click event of the 'ignore' button. Can i use maybe the .onInstFailed?

After the setup is finished i would like to set the text "Completed with warnings" or "Completed with errors".


1. See: AllowSkipFiles
2. Get a handle to that label (say, into $0) and use:

SendMessage $0 ${WM_SETTEXT} 0 "STR:New Text on Label"

Thank you very much for your reply. The first step i unterstand. This is what i'am looking for.

But i don't understand step 2. Can you please explain this with more details?


Hmmm...

One thing at a time...
If you remove the Ignore button, the user only has two options left...
A. Retry
Which if they try again and again and it still fails, their only option is...
B. Cancel

Cancel will abort installation of any further files after that point. When that happens, you still want to show a "Completed with errors" status?
Sounds like a bad idea...

Then back to your original question.. if you remove the Ignore button, how would you go about 'capturing' the effect of that Ignore button... it's not there to press? :) Seems to me you'd want to keep that ignore button, then..

So I'll just give example code for both scenarios...

==================================================
SCENARIO A: NO IGNORE BUTTON
This code will simply change the status message to a user-friendly message instead of the last file-write error.
The way this works is that -before- files are installed, it is assumed via a variable that the user -will- in fact abort the file installation.
Then in the -very last- section, which contains no further instructions, that assumption is negated by changing the variable to indicate that the user did not abort file installation.
After file installation, that variable is checked, and the status title changed accordingly.
--------------------------------------------------


!addplugindir "."
!addincludedir "."

!include "nsDialogs.nsh"
!include "winmessages.nsh"
!include "logiclib.nsh"

AllowSkipFiles off

OutFile "test.exe"

Page InstFiles InstFilesPre InstFilesShow InstFilesPost

Var UserAborted

Function InstFilesPre
StrCpy $UserAborted 1
FunctionEnd

Function InstFilesShow
FunctionEnd

Section "Files"
SetOutPath "$TEMP"
File "MoreInfo.dll"
; Locking that file so that we can force a file write error
FileOpen $0 "$TEMP\MoreInfo.dll" "r"
File "MoreInfo.dll"
SectionEnd

Section "-PostInstall"
StrCpy $UserAborted 0
SectionEnd

Function InstFilesPost
${If} $UserAborted == 1
FindWindow $0 "#32770" "" $HWNDPARENT ; Inner dialog
GetDlgItem $0 $0 0x3ee ; Status title
SendMessage $0 ${WM_SETTEXT} 0 "STR:Installation aborted by user"
MessageBox MB_OK "Installation aborted by user"
${EndIf}
FunctionEnd


==================================================
SITUATION B - Ignore button left intact.

This is largely similar to Situation A, but this time we also track whether the user pressed the Ignore button.
We can check this quite simply. If the user pressed the Abort button, then no commands after the File command that threw the error will be processed.
If the user pressed the Ignore button, then further commands -will- be processed.
All that is left to do at that point is checking whether the File command threw an error - which we can do by checking the error flag. (IfErrors / ${If} ${Errors}). Based on that, we can then set another variable indicating that there were errors that were ignored by the user.
--------------------------------------------------

!addplugindir "."
!addincludedir "."

!include "nsDialogs.nsh"
!include "winmessages.nsh"
!include "logiclib.nsh"

AllowSkipFiles on

OutFile "test.exe"

Page InstFiles InstFilesPre InstFilesShow InstFilesPost

Var UserAborted
Var UserIgnoredError

Function InstFilesPre
StrCpy $UserAborted 1
StrCpy $UserIgnoredError 0
FunctionEnd

Function InstFilesShow
FunctionEnd

Section "Files"
SetOutPath "$TEMP"
File "MoreInfo.dll"
; Locking that file so that we can force a file write error
FileOpen $0 "$TEMP\MoreInfo.dll" "r"
ClearErrors
File "MoreInfo.dll"
${If} ${Errors}
StrCpy $UserIgnoredError 1
ClearErrors
${EndIf}
SectionEnd

Section "-PostInstall"
StrCpy $UserAborted 0
SectionEnd

Function InstFilesPost
FindWindow $0 "#32770" "" $HWNDPARENT ; Inner dialog
GetDlgItem $0 $0 0x3ee ; Status title
${If} $UserAborted == 1
SendMessage $0 ${WM_SETTEXT} 0 "STR:Installation aborted by user"
MessageBox MB_OK "Installation aborted by user"
${ElseIf} $UserIgnoredError == 1
SendMessage $0 ${WM_SETTEXT} 0 "STR:Completed with user-ignored errors"
MessageBox MB_OK "Completed with user-ignored errors"
${EndIf}
FunctionEnd

==================================================

I hope that's more-or-less what you were looking for.

Ohhh... Thanks a lot! Your "SCENARIO B" is great!!!

My setups install ca 5000 files. So i have many many "File "MoreInfo.dll" or "File /r .\Files\*.*" operations im my NSIS script. When i must write after every "File" operation your code "${If} ${Errors}..." it was ... hm ... thick market. Apart from other operations e.g. WriteRegString, RegDLL, Delete ...

Currently i will use your solution of scenario B. Thank you!

In future it was very comfortable when NSIS contains a event (for example .onAnyErrorOccured). In this event i can change a Variable. At the end of the setup i could change the CompletedText.


Well you don't have to do it after -every- file command.

You could do..


ClearErrors
File
File
File
File
File
File
File
File
${If} ${Errors}
.. etc.

And if any one of those File commands threw an error, that will still trigger.

But you have to be very careful to check for other commands that may commonly set the Error flag without actually being a hard error. E.g. DeleteRegValue will set the Error flag if the value you're trying to delete doesn't exist. You're not very likely to care.. you just wanted the value gone and if it's not there to begin with - well, whatever. But you'll still have to deal with that Error flag in some way.

oh... just to answer the subject of this thread: no. .onInstFailed and .onInstSuccess only run at the very end of the installer - just before the window closes. You can use that point to selectively clean up files, write things to the registry, etc. outside of regular installation.


I have changed my scipt. It works fine. Thank you very much!