NSIS Header WindowFunc

I have an idea: Along with the splash, we can call system dlls to change the window title to (AppName)Portable. Too bad I have no idea how... I know you use user32.dll...
I'll go check out MSDN.

John wants the portable apps to be distinctive, if you were to change the title from 'OpenOffice.org Impress' to 'OpenOffice.org Impress Portable Provided by PortableApps.com' or something.
Better than the splash, less intrusive and longer lasting.
Somebody know how to work MSDN?

I think I'm going to get rid of SearchProcessPaths (but I'm keeping a copy!!).

Yeah, it would probably be the handiest example implementation of a user_func -- that's why I suggested including it as an example. The other two (if you wanted to include that many) could be:

Page instfiles                  ; show the log screen
ShowInstDetails show            ; show details on the log screen
OutFile "testproc.exe"

!include ProcFunc.nsh
!insertmacro EnumProcessPaths
!include FileFunc.nsh
!insertmacro GetRoot

Var SEARCHSTRING
Var SEARCHLEN
Var SEARCHRESULT

; Show first process found with a particular name (e.g., "foo.exe")
;
Function user_func1 ; [processpath] [PID]
    Exch $0 ; process path, return value
    Exch
    Exch $1 ; PID
    Push $2
    StrCpy $2 $0 "" -$SEARCHLEN ; $2 = right($0,len("\foo.exe")
    StrCmp $2 "\$SEARCHSTRING" 0 NoMatch
        DetailPrint `    Found a process matching "$SEARCHSTRING":`
        DetailPrint `    [pid=$1] $0`
        StrCpy $SEARCHRESULT 1  ; tell script we found one
        StrCpy $0 0             ; return = stop looking
        Goto TheEnd
    NoMatch:
        StrCpy $0 1             ; return = continue looking
    TheEnd:
        Pop $2
        Pop $1
        Exch $0                 ; Push return value
FunctionEnd

; Show all processes with executables on a particular filesystem.
;
Function user_func2 ; [processpath] [PID]
    Exch $0 ; process path
    Exch
    Exch $1 ; PID
    Push $2
    StrCpy $2 $0 $SEARCHLEN     ; $2 = left($0,len("X:\")
    StrCmp $2 $SEARCHSTRING 0 NoMatch
        DetailPrint `    [pid=$1] $0`
        Goto TheEnd
    NoMatch:
        ; do nothing
    TheEnd:
        Pop $2
        Pop $1
        Pop $0
        Push 1                  ; return = continue looking
FunctionEnd

Section Main
;   Test1:
        ; pre-compute $SEARCHSTRING and $SEARCHLEN for user_func
        StrCpy $SEARCHSTRING "calc.exe"
        StrLen $SEARCHLEN "\$SEARCHSTRING"
                                    ; i.e., len("\calc.exe") = 9
        DetailPrint `Looking for first process called "$SEARCHSTRING"...`
        ${EnumProcessPaths} "user_func1" $0
        StrCmp $SEARCHRESULT 1 0 NotFound
            DetailPrint `Success!`
            Goto Test2
        NotFound:
            DetailPrint `Couldn't find one; try running Calculator.`
    Test2:
        DetailPrint ` `
        ; pre-compute $SEARCHSTRING and $SEARCHLEN for user_func
        ${GetRoot} $EXEPATH $0      ; $0 = root directory of filesystem this
                                    ; ...script was run from
        StrCpy $SEARCHSTRING "$0\"  ; add trailing slash
        StrLen $SEARCHLEN "$SEARCHSTRING"
                                    ; e.g., len("X:\") = 3
        DetailPrint `Listing all processes from same volume as this Test ($0)...`
        ${EnumProcessPaths} "user_func2" $0
        DetailPrint `Done.`
SectionEnd

And, yes, I actually tested this one.   Note how Test2 lends itself readily to an eject script...

I think your Multi and Exclude ideas are interesting. But for your example, you could use the ${Execute} macro to return the exact PID you're concerned with, allowing you to skip the ProcessWaitExclude.

Actually, ${Execute} execs soffice.EXE which in turn loads soffice.BIN. The EXE doesn't create any windows, only the BIN does. I would imagine that other programs spawn multiple processes when launched as well. That's why my test code (OOo) first looks for running processes that match the target, then launches the parent process that spawns the target, then looks for a matching target that wasn't there in the first place. At that point, we have a useful PID (even if AllowMultipleInstances=true). For the majority of programs, the ${Execute} macro I requested would work beautifully.

Could lead to a wiki of your own

I was kinda hoping you'd consider merging them with your ProcFunc.nsh and correcting any stupid coding errors (remember, I fired my code reviewer :P). I don't mind "{based on|influenced by} {idea|code|crap} contributed by [Real Name]" or similar, but otherwise, I prefer to influence the world behind the scenes. :cool:

-hea

P.S. My POS XPSP2 machine BSOD'd when I was mostly done with this post. Grrr.

Fortunately I was using Firefox with browser.sessionstore.enabled=true (which by default writes to disk only every 10 sec, not every page load). Unfortunately, since posting requires logging in, Session Restore didn't bring back my unfinished post. So, I had to manually edit my sessionstore.bak to retrieve the contents of my unposted comments and unencode all of the %nn nonsense. Minor pain, but thank god I was using Firefox!