Animaether
24th November 2008 12:06 UTC

depending on the level of errors you need, you can either go with the default callbacks (installation failed, user abort, etc.) or wrap important parts of your code in..

clearErrors
<code>
ifErrors

bits, where you set the error details yourself (NSIS doesn't have a variable that contains the error message - if even applicable).

Then use something like inetc ( http://nsis.sourceforge.net/Inetc_plug-in ) to submit the data to your website (either GET or POST).

afisk
25th November 2008 02:16 UTC

Thanks a lot. I noticed the inst failed callabck, but is that called on any failure? If so, it's perfect. The documentation's slightly confusing on this point.

On ifErrors, that basically checks if the return code of the anything in the prior code block was non-zero? It's a non-zero return code anywhere in the code block, not just the last call, right?

Thanks very much.

-Adam

Animaether
25th November 2008 02:53 UTC

Originally posted by afisk
Thanks a lot. I noticed the inst failed callabck, but is that called on any failure?

'fraid not - it's only called in one situation: the user hitting the Cancel button on the InstFiles page (the page where actual file installation commences).
The cancel button itself is only enabled if a File couldn't be extracted, or script code (in one of the sections, for example), called Abort.

So if you have, for example, a page that grabs a piece of registry information on which your installer depends, and that registry information is missing, .onInstFailed won't be called, as missing registry information isn't an installation error problem.

If you have such situations to deal with, then, more than likely, you'd want to work with the ClearErrors/code/IfErrors bit as that will give you a bit more information than just "the user hit cancel while installing files".

Originally posted by afisk On ifErrors, that basically checks if the return code of the anything in the prior code block was non-zero? It's a non-zero return code anywhere in the code block, not just the last call, right?

Correct - it's for all of the code since the last ClearErrors. If any call after the last ClearErrors sets the error flag, then IfErrors will be true - you won't be able to tell which call, exactly, caused the error so choose your code blocks carefully.

In theory it should be possible to wrap every NSIS command with an error handler, but it would be quite a bit of work on the level of LogicLib... and reading through logiclib code makes my head hurt ;) Perhaps a future version of NSIS will have an internal variable or stack that contains (a) userfriendly error message(s), at least for developers' use.