I have just started playing with creating a Suite project in InstallShield 2012 and have not figured out how to accomplish certain tasks I was able to do before. I hope these haven't been asked before, at least I haven't found them yet. 1. Is it possble to run Custom Actions during the execution of a Suite installation? If it is possible, how might that be done? 2. From within a Suite installation, is it possible to access the registry to create/read/update registry entries? Or will it have to be done through Custom Actions, if Custom Actions are possible? 3. From within a Custom Install, is there a way to define dependent features that must be included for installation if one of the primary features is selected? Thanks in advance.
A lot of this depends on what you want to do with your custom actions. A suite is logically split into the UI phase plus the execution phases of the packages it installs. So gathering data to ask questions in the UI makes a lot of sense, and we'll be covering how to do this on the blog soon. But custom actions that modify the system do not make much sense and should typically be part of the packages that are being installed.
Question 2 is similar, but definitely sounds like the type of action that does make sense in a suite.
Question 3 mostly follows MSI style behavior. The tree itself only offers enforcement of requiring your parent feature; sibling or cousin features are not verified in any fashion. However if you only offer people buttons to select features, then you can enforce this in other ways.
Michael, thank you for your reply. Is there a date when we might expect to see the blog covering how to do custom actions in a suite project? And where might we find the blog once it is posted? the InstallTalk blog?
Michael, is it possible for an Action for a Control on a Wizard page to run a custom action to perform the functions that need to be done during the installation?
That's the idea, assuming that you're not talking about actual installation steps. Actions in the UI are intended to be somewhat similar to a custom action scheduled in the User Interface in that they should probably not touch the machine; instead they should just read and write properties, or possibly temporary files. They can be one of several predefined things (such as setting suite properties, or opening a document) or a call into custom code which can do those things and more.
Sure, validation actions are a particular kind of action that are initiated by edits to controls rather than just button clicks. I think we'll have to blog about this too, but the short version is you write it like any other action's code, and set a property. Meanwhile that dialog needs some controls (perhaps text, perhaps images) whose visibility is controlled by the property that the validation action sets.
You can probably most easily prototype the reaction to validation by adding some buttons or checkboxes associated with the property you would want to set. Then click or check them accordingly to see your validation messages appear.
