What sort of scenario are you looking to see an example describe? We have a lot of information on the InstallTalk Blog, with more coming every week, but no single post we've got up there takes you end to end. For a real-world example, InstallShield 2012 itself installs as a suite, but doesn't really take much advantage of the new capabilities in the Suite projects.
I am trying to find out if I can take the installers that I currently have and use the suite project for them. There are three installers. The first one does not install anything; it creates .ini files from the user’s responses that are used in the second and third installers. The second installer determines if an upgrade is happening or not (using info from the .ini file), does some backups if an upgrade, and then launches the third installer (Don’t ask me to explain, I did not write this). The third installer also uses the .ini files created in the first installer. So, can the suite project be run so that the first installer can be run by itself (more than once if necessary), and when ready, the second installer can be selected to be run (it must always run (whether upgrade or new installation)), and it will always submit the third installer. So, there must be an installer selection option (run the first installer, or run the second installer). Not having read the literature yet (I know…I know), if this can be done, are we talking about have three installers that are being managed by this suite project, or, are we talking about there being only one installer from which different features(?) can be selected (remember that nothing is installed (no A\R\P etc. entries) if the first installer is selected).
I think a lot depends on how much of that exact flow you want to keep. If you need it to do INI work, you'll probably find it easiest to drive three packages from the suite. If you keep the first package as a dependency package, its presence won't impact the mode of the suite (or whether the suite writes an ARP entry), so it could be made to run multiple times. But it definitely sounds like an odd set of requirements that don't match our usual flow.
Regardless of the number of packages in the underlying architecture, you would probably make this appear as if it's a single installer with three features, or alternately with two features and some buttons. I think. I haven't fully understood the scenario. If it helps, Suite projects generally try to take MSI concepts one level wider. For example, Suite features typically map to packages the way MSI features map to components.
