healy76
6th April 2009 15:42 UTC
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".
Animaether
7th April 2009 01:41 UTC
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"
healy76
7th April 2009 08:26 UTC
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?
Animaether
7th April 2009 09:43 UTC
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.
healy76
7th April 2009 10:10 UTC
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.
Animaether
7th April 2009 10:23 UTC
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.
Animaether
7th April 2009 12:48 UTC
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.
healy76
8th April 2009 10:10 UTC
I have changed my scipt. It works fine. Thank you very much!