Repeat automatically install of files for INI configured # of times

Hello,

this is a tricky thing I've been asked to do, and I don't even know if it's possible in NSIS:

The installer should ask for an install path, and then install a file under the given folder but with different name suffixes.

For example, test.exe should become test_a.exe, test_e.exe, ..., test_z.exe.

(Actually it's even hader because I must install different group of files, but for simplicity let's suppose one file only, the main problem should be the same)

Easy till here, now comes the difficult part:

The "a", "e", .. "z" strings should be taken from an ini file which is in the same folder as the setup program, for example containing something like

suffix_1=a

suffix_2=e

.

.

suffix_<n>=z

The number of copies is not known at NSIS compile time, but is found in the INI file.

I searched for loop constructs in NSIS but couldn't find any, do you think the above stuff can be done?

Thank you,
Mario

yep.. totally doable..

I think you'll be well on your way once you've found the loop constructs, so...

Totally amazing then!

Indeed, it should be much easier with this library extension.

Digging....

Thank you so much,
Mario

Getting even harder now ...

can I also have a number (and name) of sections (that is, components) dependant on the content of the external ini file?

It doesn't seem you can declare a dynamic number of sections.

Any suggestions or details?

Thanks,
Mario

nope - no dynamic section numbering support.. you could, however, add as many as you could possibly foresee, defaulting to blank titles (thus they're hidden) and unselected (/SO), then fill in the titles dynamically (showing those that are needed), and use the section flags bits to see which the users ends up actually selecting.
( see also LogicLib.nsh and Sections.nsh )

Sections can be accessed numerically, so another Loop would allow you to iterate over them at runtime.

Thank you very much again!

I have now defined 30 sections, and can show only the ones used by the ini file. Great.

Now the problem is that each section should install content dependant on the Section Text (set by SectionSetText within the init handler).

Is it possible to access the section index text from within the section without knowing the section index itself?

Thank you,
Mario

Given the dynamic allocation, not really (I think).

However.. I'm not sure why you'd need to?

Basically, the Sections are functioning just as placeholders so you can show them on the Components page to the user, letting the user check/uncheck sections as needed.

After that, e.g. in InstFiles, you'd just have a function that...
1. loops over the dynamic sections by index
2. checks if the section is selected
3. gets that section's text
4. decides on the action to take based on that text (presumably)

Note that unless that action is dynamic as well, I'm not sure you'd need dynamic sections? I.e. if there are 10 possible sections with corresponding actions to take and you only need to show/hide them based on that ini file, you could just as well hardcode those sections with their actions within them, and only use the SectionSetText and section selection code to hide/unhide / preselect them?

Actually, all the sections should do the same thing, but the names of the files installed and other operations depend on the section name (taken from the ini file).

But, if I can inject a that does the loop and calls a custom install function for each named section then I would be done.

I have searched around, but cannot find a way to inject my function in the standard instfiles page. Do I have to make a custom page replacing the standard instfiles or am I missing something?
Thanks,
Mario

Mmm just found the standard page callbacks, and maybe another method to get the job done...

- Mario

ahh okay, understood.

As for where to place the code - I'd say add...

Section "-Parse dynamic sections" 
[code here]
SectionEnd 

...somewhere - presumably either just before or just after your dynamic sections (order doesn't matter much.. could be right in the middle, really, just isn't logical).

Again, thanks a lot.

I can now concentrate on the code for the single section, the skeleton is done and seems to work fairly well.

This is the first setup I do in NSIS (what a start!), I'm not sure I could do something like this in InnoSetup. NSIS is apparently a bit more hardcore (you have do do more things manually), but this is also the key to get advanced features quicker.

- Mario

NSIS is indeed -very- powerful, but also very hands-on. There's really only two alternatives (besides InnoSetup)..
A. Windows Installer-based installers.. in which case, look to WiX. Not too particularly powerful but it does let you do things in Microsoft-approved manners, lets your company slap a "Designed for Windows *" sticker on the box (presuming you also qualify for the other rules in that), lets SysAdmins deploy your installer and muck around with it using group policies, etc. I think its biggest advantage at this time is 64bit interaction support.
B. Writing your own custom installer software. Not pretty 😉