/build/static/layout/Breadcrumb_cap_w.png

Feature Request State Conditions? during MaintenanceMode

Hi guys,

In my selection dialog/custom setup dialog I have conditions (on the "Next" button control) querying requested feature state and showing dialogs according to selected feature (from selection tree)

&FEAT1 >= 3 -> FEAT1DIALOG
&FEAT2 >= 3 -> FEAT2DIALOG

During install this works, but in maintenance it seems feature request states aren't populated? I mean, during selection in SelectionTree nothing seems to change in realtime in the states.

Is this because MigrateFeatureState isn't run during MaintMode before first dialog comes up?

Some geeks here, who can tell me how to conditional syntax this crap in CustomSetup/Selection, so it works in MaintMode too?

EDIT:
Don't wanna use MsiGetFeatureState. Doing a CA only for this small problem seems a little bit oversized

0 Comments   [ + ] Show comments

Answers (5)

Posted by: captain_planet 13 years ago
Black Belt
0
I've just done a quick test and it worked ok for me - .....your UI sequence may look similar to this towards the end:

MaintenanceWelcome
SetupProgress
ExecuteAction

Try putting your dialog between MaintenanceWelcome and SetupProgress. It works for me, and if it works for you the installer logs will probably tell you why....
Posted by: rattata 13 years ago
Senior Yellow Belt
0
MaintenanceWelcome -> MaintenanceType -> CustomSetup -> FEAT1Dialog OR FEAT2Dialog OR DestinationFolder

CustomSetup <- selection tree
DestinationFolder = &FEAT1 < 3 AND &FEAT2 < 3
FEAT1Dialog = &FEAT1 >= 3
FEAT2Dialog = &FEAT1 < 3 AND &FEAT2 >= 3

Still no luck yet... REINSTALL >< FEAT1/2 does not help either

Are you really sure you are doing MaintenanceMode modify? Scenario: Instlal all Features (INSTALLSTATE_LOCAL) during first install (conditions work), then start again and do Modify, and crap: conditions don't work second time surprisingly... It directly shows DestinationFolder dialog (which means that it just couldn't resolve feature states)
Posted by: pjgeutjens 13 years ago
Red Belt
0
once the feature has been installed , won't the actual feature state for these features be -1 during maintenance-mode (no action)?
in any case run an /LV* log and look at the Installed: Request: Action: lines for your features. If it says no action I'm pretty sure this corresponds to -1 feature state. Since it's not entirely clear to me what the desired effect is during maintenancemode, I'd say rebuild your conditions accordingly [;)]

PJ
Posted by: rattata 13 years ago
Senior Yellow Belt
0
desired: 1. custom dialogs when features selected 2. mutually exclusive features (two hidden subfeatures... in one of the custom dialogs I handle that with ADDLOCAL and REMOVE)

log: "Request: Null" :-)

all the time I thought it's not populating the feature request states because of misbehaviour... but you're right, now it makes sense for me too, because WI checks for the components and everything is installed, in Modify we get no REINSTALL triggered... so feature request state is Null - or "-1" like you said... Is it really "-1"? I will try to condition with that then...
Posted by: captain_planet 13 years ago
Black Belt
0
Yeah, i created a simple type 38 custom action like this:

test = Session.FeatureRequestState("Complete")
MsgBox test

and put it in different parts of the UI sequence. If i put it before where I stated above, it returned -1. If i put it where I mentioned above, it returned 5.
Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.
 
This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ