MUI2 InstFiles Leave custom function call order should change?

I was poking at a little something something and realized that I can use...

!define MUI_PAGE_CUSTOMFUNCTION_LEAVE FunctionName 

...all I want, but if I'm using it to change the header text controls $mui.Header.Text and $mui.Header.SubText, then MUI2 is going to happily override that change with its internal code; it calls the custom function first, and runs its own code second.

Shouldn't that be the other way around?

( The same actually applies to the Pre function as well and probably applies to other pages. )

Because MUI uses defines to set those texts, I can't override them during runtime in order to get MUI to use my own strings either. Nor can I cheat by using 'goto mui.endheader_done' because it calls a Function - from which that won't work 😁

As far as I can tell - at least in the case of the InstFiles page - there's no harm in swapping the order either.

Thoughts?

Sample script:

!include "MUI2.nsh"
!include "winmessages.nsh"
outfile "test.exe"
ShowInstDetails show
!define MUI_PAGE_CUSTOMFUNCTION_LEAVE InstFilesLeave
!insertmacro MUI_PAGE_INSTFILES
Section
SectionEnd
Function InstFilesLeave
  sendMessage $mui.Header.Text ${WM_SETTEXT} 0 "STR: This doesn't stick"
  sendMessage $mui.Header.SubText ${WM_SETTEXT} 0 "STR: ...neither does this"
  MessageBox MB_OK "Now it's there... click OK and *poof*"
FunctionEnd
!insertmacro MUI_LANGUAGE "English" 

Aren't you trying to set the next page's texts doing this? Unless you have omitted MUI_FINISHPAGE_NOAUTOCLOSE (SetAutoClose false).

Stu

No, I'm definitely trying to affect the IntFiles page's header text 🙂

The MUI_FINISHPAGE_NOAUTOCLOSE define doesn't really play any role in this except that if one were to autoclose the InstFiles page, and the next page is the MUI Finish page (doesn't affect other pages) setting the text would be moot (well, ephemeral to the point of being moot).

!include "MUI2.nsh"
!include "winmessages.nsh"
outfile "test.exe"
ShowInstDetails show
!define MUI_PAGE_CUSTOMFUNCTION_LEAVE InstFilesLeave
!define MUI_FINISHPAGE_NOAUTOCLOSE
!insertmacro MUI_PAGE_INSTFILES
!insertmacro MUI_PAGE_FINISH
Section
    Nop
SectionEnd
Function InstFilesLeave
  sendMessage $mui.Header.Text ${WM_SETTEXT} 0 "STR: This doesn't stick"
  sendMessage $mui.Header.SubText ${WM_SETTEXT} 0 "STR: ...neither does this"
  MessageBox MB_OK "Now it's there... click OK and *poof*"
FunctionEnd
!insertmacro MUI_LANGUAGE "English" 

You should see the function, and MUI's own code*, being triggered without going to any next page.. the nomer "Leave" isn't entirely correct for the InstFiles page given its behavior, I suppose.

* In MUI's own code, defined in Contrib\Modern UI 2\Pages\InstallFiles.nsh, this behavior is used to toggle between the two define'able texts wrt the installation being successful / having failed (Abort having been called during InstFiles).

In theory this would probably affect the next page (presuming a page with a MUI header; the Finish page is not one of those) except that MUI always uses a Pre function to adjust that page's Header itself (either by the user-defined header texts, or its own internal ones).

So anyway, the problem is that after I press OK in the MessageBox, my custom text disappears - I don't think it should.. thoughts? 😁

Perhaps you should submit a feature request.

Stu

Sounds good - just wanted to make sure I didn't miss something (non)-obvious that would prevent having to change MUI code 🙂

In this particular case, a runtime toggle could also be added that would simply tell MUI to skip its UI handling code.

I'll check into the other pages and such and see what the ramifications of call order changes might be.

Request ticket logged in the mean time - thanks 🙂

*smacks forehead*

Of course, one can use a variable in MUI's defines for MUI_INSTFILESPAGE_FINISHHEADER_(SUB)TEXT and MUI_INSTFILESPAGE_ABORTHEADER_(SUB)TEXT

I still think the call order is *technically* wrong, so I'll leave that ticket op and amend it - but the obvious workaround hit me anyway.

Yes I was going to say that but it isn't very elegant.

Stu

I think it's as elegant as it's going to get within the MUI framework... and beats adjusting the source at the moment 🙂