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

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

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....
Answered 05/12/2010 by: captain_planet
Second Degree Brown Belt

Please log in to comment
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)
Answered 05/12/2010 by: rattata
Senior Yellow Belt

Please log in to comment
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
Answered 05/12/2010 by: pjgeutjens
Red Belt

Please log in to comment
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...
Answered 05/12/2010 by: rattata
Senior Yellow Belt

Please log in to comment
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.
Answered 05/12/2010 by: captain_planet
Second Degree Brown Belt

Please log in to comment
Answer this question or Comment on this question for clarity