getting return string value

zanz
17th July 2008 17:22 UTC

getting return string value
Hi all,

I'm still very new to NSIS script. I'm trying to convert our installers to NSIS.

I've organized all the common functions into a common header file, which I include in the *.nsi file.

From some functions, I need a string or in return value from header file to the *.nsi file. How can I achieve this? Any hints will be appreciated. Thanks.

LoRd_MuldeR
17th July 2008 17:51 UTC

You basically have to ways to return values for (or pass arguments to) a function, no matter where it's located: Push the value on the stack, so the caller can pop it off the stack after function return or you write the result directly to a user var. The latter case is not a good solution, as variables might be overwritten unexpectedly. I'd use a macro to hide the actual call:

!define MyFunction "!insertmacro _MyFunction"

!macro _MyFunction return_var arg1 arg2 
  Push "${arg1}"
  Push "${arg2}"
  Call _MyFunctionFunc
  Pop ${return_var}
!macroend

Function _MyFunctionFunc
  ; First of all pop two arguments from the stack
  ; Do some important calculations here
  ; Finally Push the result onto the stack
FunctionEnd

You'd call it like that:

${MyFunction} $0 "This is arg1" "This is arg2"
DetailPrint "Function returned: $0"

Be aware:
If you use any user variables ($0 to $9) inside your function, you should save those on the stack first and restore them before your function returns! Otherwise variables get overwritten unexpectedly again...

(Handling arguments/returnvalues *and* the saved vars on the stack at the same time can create some pain though, Exch might help to solve that)

zanz
18th July 2008 18:15 UTC

Thanks LoRd_MuldeR, your answer is really helpful.
These might be stupid questions, but I need to ask them:

- We can declare a section within a function. If we can, is it a good practice for NSIS script?

- It seems I can organize the installation better if i create multiple install sections in the script. Is it a good practice?

I'd really appreciate any help. Thanks!

Comperio
18th July 2008 21:18 UTC

Enclosing sections in a function would be a bad idea. The purpose of a function is to be able to re-use code by calling the function more than once. If you had a section defined in a function, then you'd be adding the section every time.

If you have a need to dynamically add sections, then I'd enclose the definitions inside macros and the use !ifdef or !ifmacdef to determine whether or not to include the section during compile time.

Or, maybe you just need to skip a section during runtime (based on the user's selection or type of environment.) In that case, then you can define all section at compile time, but then skip over the ones you don't need at runtime. (You can also make sections hidden if you don't want users to see them.) Have a look at SectionSetFlags and SectionGetFlags in the docs. Or consider having the contents in the entire section enclosed in an ${If} block to process only if a certain condition is met.

LoRd_MuldeR
19th July 2008 12:49 UTC

1. Multiple sections definitely are a good idea

2. You can enable/disable sections at runtime

3. You can create "hidden" sections, so the user won't see those

4. To share a section between several installer use a macro