[...]
There's another approach I can take but I'd rather be able do
everything I need to do internally, within the installer. The
other approach is basically chaining two installers.
1) Have one installer or application get the needed user input via
custom code.
2) The custom code saves the needed information on disk and then
launches the second, chained installer.
3) The main installer, on launch, will read the information on
disk and via the Distribution.dist javascript mechanism, select and
deselect the packages.
I would need to do it this way because the Distribution.dist
javascript file runs when the main installer first launches. So
the information needed that selects and deselects packages in the
main installer would have to already exist, on a file on a disk for
example, when the main installer launches.
I also know that packages can depend on packages, so if one gets
selected/delected, other packages can get selected/deselected, but
I can't do it this way.
I'd appreciate input on this.
Your solution based on an application is a good one IMHO. It would
avoid you the trouble of seeing your packages being installed without
the plugin being run (command line / ARRD/ etc.).
It might not be totally impossible to re-evaluate the choices from an
Installer plugin (with _evalItem:forAttribute:incrementOnEval: for
instance) but that solution would be unsupported,
Maybe you could also contact the mothership and see if they can offer
a better solution.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Installer-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
