cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
DLee65
Level 13

SUITE: OnBegin event cannot filter for Install only

I have a couple of events set to run OnBegin. I only need these events to run if we are installing, not repairing, or removing, or maintenance mode.

There isn't an option for Install Mode shown in the UI for the OnBegin events, but the 'Package Operation' condition check does appear. So I select this and set the package to my primary package and set the check for 'Install'. If my understanding is correct, this should work if the package is set to Install.

However, this is not the case. None of my events execute properly in the OnBegin event possibly because the installer has not evaluated the install state for each package yet.

Is there some other property I can check so that my events execute in OnBegin for install mode only?

Thanks.
Labels (1)
0 Kudos
(4) Replies
MichaelU
Level 12 Flexeran
Level 12 Flexeran

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.
0 Kudos
DLee65
Level 13

We are running a query that confirms that the client has a valid license. If the check finds a valid license, then it sets a private property value to Y. The default value is N.
The state of the wizard pages depends on this check.
I tried adding it to a Next button check but the check causes a visible delay in switching pages. That is why I moved it to OnBegin where the delay is not noticeable by the consumer.

* The check should always run for every install mode, including upgrades. We only do major upgrades.
* The check should not run for Remove, Repair, or Modify.

I do have a check that can determine if the application is already installed, but I do not have a check to know the mode I am executing. I already handle the condition where the application is not installed at all.
0 Kudos
MichaelU
Level 12 Flexeran
Level 12 Flexeran

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.
0 Kudos
DLee65
Level 13

Michael, thank you. The Page Entered event works well. If the user is very, very fast with the keyboard they notice a slight hiccup, but most users will not notice anything.
0 Kudos