As far as I know, the caption 'Change' is owned by ARP / Programs and Features, and it is only possible to enable or disable it. You can certainly make the wizard page displayed in response offer a health check option in addition to, or in place of, any of the regular maintenance options, but that won't change whether 'Change' makes sense for it. ... View more

If your prerequisite has listed specific OSs in its requirements, the problem here is that Windows is indicating it is one of the versions you have selected for the prerequisite to support. You can get Windows 10 to indicate the correct version by editing the manifest used in setup.exe to declare support for Windows 10 by adding a supportedOS element to \Support\setupexe.*.manifest. Note that InstallShield 2014 predates and does not officially include support for Windows 10, so you will want to verify that things are working correctly for all the scenarios you do support. Alternately, if you can find a registry key, or file or versions that is either available only on Windows 10 (or only on Windows before 10), that may be an alternate way to determine the version, and get the same effect without declaring support for Windows 10. ... View more

This isn't typically a question that makes sense. By blocking non-administrators from launching your installer, you are preventing an "over the shoulder authorization," instead requiring limited users to log off and have an administrative user log in. If you do not prevent this, so long as you correctly mark items that need elevation (this is the default for packages, and is configurable for actions), the suite will elevate once and invoke the relevant items in the elevated context. That said, if you absolutely do need to block this scenario, you can create an action for your suite using C++ or InstallScript. The InstallScript code could call either Is(USER_ADMINISTRATOR, "") or Is(USER_INADMINGROUP, "") depending on your exact needs. See also SuiteSetProperty for communicating this information back to the suite. ... View more

Can you detect the v1 version separately from the v2 version? If so, I would probably lean towards having the v2 package in your suite detect only v2, and in its Package Configuring event, have it run an action that uninstalls v1, conditioned to run only if v1 is present. I haven't explicitly tried this, but it just feels to me like it puts the right pieces in the right places. It should apply equally well to first-time suite installs and suite-over-suite upgrades. An optional variant of this is to create an exe package, marked as a dependency, with reversed detection conditions for the v1 package, and an Install operation command line that actually removes it. Order it to come before the v2 package, and it mimics the action approach, but requires at least one file be included in the package. This would have been the recommendation before actions were available. I suspect even better would be to figure out how to have v2 replace v1, as it would probably be simpler to maintain than all the version-specific conditions for the above approaches. (But I'm saying that without knowing why your packages cannot replace their preceding version, so remember it's an unfounded opinion.) ... View more

I'm not sure I understand where the complexity is coming from. If we model this off a simple case, one might have v1 of a MSI package that needs to be upgraded to v2. It shouldn't inherently matter how v1 got onto the machine; the Suite with v2 can then install v2 which will either upgrade v1 or install v2 fresh. This shouldn't fall down unless the detection condition for the MSI was incorrect, and for an MSI package that shouldn't happen unless it's changed. And that should scale without difficulty to several MSI packages that apply either a minor or major upgrade. InstallScript packages should be similar, although they don't have the same names for their upgrades. I suppose InstallScript MSI or other EXE redistributables could provide challenges. So what are the added complexities in your case, besides just having several packages? Do you have packages that cannot automatically upgrade just by installing v2 over v1, so must be removed? Do you have packages that you need to remove manually because they are not related to the ones in your new Suite? Do your detection conditions that indicate v2 is installed because they detect v1's presence? Do you need to specify default features by detecting v1 and turning on v2's feature? Are you trying to remove one or more previous Suites that have a different Suite GUID? ... View more

Hmm, okay. Here are a couple possible approaches within the current framework. Otherwise you'd probably need an event that occurs after the mode is determined, but before the wizard is shown. If the check is not harmful to run even in maintenance scenarios, but you just don't want its value, consider populating a secondary property with its results, then copying it into the primary property on the Next button for appropriate scenarios. (A Set Property action should be virtually instantaneous.) If the check is harmful to run during maintenance scenarios, consider running it on the Page Entered event of the first pages shown. (I would expect this delay to be less noticeable than the delay on the Next button.) If the delay stems from the technology implementing the action that checks, rather than the check itself, see if you can get your check implemented in C++ as that has less initialization latency than, say, InstallScript. If the delay is due to something like network latency, however, this is unlikely to help. ... View more

Agreed, we haven't yet evaluated the mode condition as of OnBegin, so there's an ordering problem here. Can you share a little more detail about why you need to run something this early, or why it needs to be for "install only"? I see two likely outcomes. In one, we introduce another event that occurs a little later than OnBegin, but still before the UI is shown (if it will be). In the other, you can use a condition that performs part or all of the checks in the mode condition. For example, you might check either or both of the following: SuiteInstalled (your guid, possibly ignoring lesser versions; this is currently just a registry key check so it has no ordering dependencies) Copy of a detection condition of one (or more) of your packages (this depends on the package type, but also has no weird ordering dependencies) This would let you either target the overall suite status, or the status of a single package of the suite, depending on what your decision reflects. ... View more

Which property do you have associated with the progress bar in your suite? You will get different behavior depending on whether it reads ISInstallProgress or ISParcelProgress. ... View more

[CODE]11-5-2015[11:15:31 AM]: Action returned value 0x80020005[/CODE] The 80020005 indicates a type mismatch. Is your function's prototype correct? Make sure it accepts an OBJECT, and not, say, a HWND. ... View more

Let's see, you came from InstallShield 2013, right? Have you undone the custom steps to support InstallScript actions in that version? They're no longer necessary, and in fact they get in the way. See this blog post for details: http://blogs.flexerasoftware.com/installtalk/2014/06/upgrading-suiteadvanced-ui-projects-that-used-installscript-actions-to-installshield-2014.html ... View more

If you want the parenting of the window to be correct, you have to use UI actions (including methods from ISuiteUIExtension) to show your message. These aren't currently available to PowerShell actions (or managed or InstallScript actions), so there is no parenting information, and then focus stealing prevention can cause the message box to be covered. ... View more

You may be able to get this with a custom validation action, but those currently have to be written in C++ or other native code, and that's only if the built-in cursor logic fits your needs. Other that that I'm out of ideas; we don't currently have a way to control the cursor position or put custom fields on a wizard page or secondary window. ... View more

Right, gotcha. Hiding it doesn't work well if it's the parent of features you still want to show. ... View more

I'm going to take a stab in the dark here and guess that you're building an InstallScript project, and have SP1 installed. If so, we've got a better fix coming down the pipes soon, but in the mean time you can revert MediaBuild40.dll to the version that shipped with InstallShield 2015 RTM. Let me know if you need help finding that file, or if you have a support contract our support team can definitely assist with that. ... View more

If you change the feature's Visible setting to No, it shouldn't show up in the InstallationFeatures tree. It should be possible to reference the FEATURE[ ].installState or FEATURE[feature-name].actionState pseudo-properties in the Visible condition of a wizard page. ... View more