Yes that's true, but without the definition of
MUI_ABORTWARNING/MUI_UNABORTWARNING i don't get the
appropriate language strings for the message. On the other
side, if I define MUI_ABORTWARNING/MUI_UNABORTWARNING i
cannot provide my own .onUserAbort ... Or am I wrong?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I think MUI_CUSTOMFUNCTION_ABORT/MUI_CUSTOMFUNCTION_UNABORT
give the user a way to provide it's own abort function. But
this function is called after the default message box has
been displayed (see macro MUI_FUNCTION_ABORTWARNING in
system.nsh). To suppress the message box I'm not allowed to
define MUI_ABORTWARNING/... So I can provide may own message
box with the function defined by
MUI_CUSTOMFUNCTION_ABORT/... But the problem is: if I don't
define MUI_ABORTWARNING I also suppress translations
provided for the message box (see macro MUI_LANGUAGEFILE_END
in system.nsh) and I cannot use them for my own message box.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Modifying the System.nsh would be one solution. But
unfortunately not for me. Because I implement an installer
for a customer (company) that gets the sources too, because
they must be able to modify the implementation and compile
it with the latest NSIS release if required. So I cannot
change files provided by NSIS.
I would prefer a solution provided by NSIS. An easy solution
could be to just modify the line
No, sorry, that's not an acceptable patch. It doesn't look
like any other MUI setting. A define like
MUI_ABORTWARNING_CANCEL_DEFAULT, which takes no arguments,
should be created and documented.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Logged In: YES
user_id=584402
For now, you can define your own .onUserAbort and use
MB_DEFBUTTON1 or MB_DEFBUTTON2.
Logged In: NO
Yes that's true, but without the definition of
MUI_ABORTWARNING/MUI_UNABORTWARNING i don't get the
appropriate language strings for the message. On the other
side, if I define MUI_ABORTWARNING/MUI_UNABORTWARNING i
cannot provide my own .onUserAbort ... Or am I wrong?
Logged In: YES
user_id=584402
For that you have MUI_CUSTOMFUNCTION_ABORT and
MUI_CUSTOMFUNCTION_UNABORT.
Logged In: NO
Hi kichik,
thanks for the fast response.
I think MUI_CUSTOMFUNCTION_ABORT/MUI_CUSTOMFUNCTION_UNABORT
give the user a way to provide it's own abort function. But
this function is called after the default message box has
been displayed (see macro MUI_FUNCTION_ABORTWARNING in
system.nsh). To suppress the message box I'm not allowed to
define MUI_ABORTWARNING/... So I can provide may own message
box with the function defined by
MUI_CUSTOMFUNCTION_ABORT/... But the problem is: if I don't
define MUI_ABORTWARNING I also suppress translations
provided for the message box (see macro MUI_LANGUAGEFILE_END
in system.nsh) and I cannot use them for my own message box.
Logged In: YES
user_id=584402
You're right, my mistake. You'll have to modify System.nsh
for this one. A patch would be gladly accepted, of course.
Logged In: NO
Modifying the System.nsh would be one solution. But
unfortunately not for me. Because I implement an installer
for a customer (company) that gets the sources too, because
they must be able to modify the implementation and compile
it with the latest NSIS release if required. So I cannot
change files provided by NSIS.
I would prefer a solution provided by NSIS. An easy solution
could be to just modify the line
MessageBox MB_YESNO|MB_ICONEXCLAMATION
"${MUI_ABORTWARNING_TEXT}" IDYES mui.quit
in the macro MUI_ABORTWARNING (system.nsh) like this:
MessageBox
MB_YESNO|MB_ICONEXCLAMATION${MUI_ABORTWARNING_OPTIONS}
"${MUI_ABORTWARNING_TEXT}" IDYES mui.quit
So I could add the required options just by defining
MUI_ABORTWARNING_OPTIONS.
The same is required for the macro MUI_UNABORTWARNING.
I would be glad if you could provide this small patch with
the next release :-)
Again, thanks for the fast response!
Logged In: YES
user_id=584402
No, sorry, that's not an acceptable patch. It doesn't look
like any other MUI setting. A define like
MUI_ABORTWARNING_CANCEL_DEFAULT, which takes no arguments,
should be created and documented.
Logged In: NO
Yes, that's OK :-)
Thanks.
Logged In: YES
user_id=584402
Added MUI_ABORTWARNING_CANCEL_DEFAULT.