Suite Feature Selection Tree Question

[rguggisberg]

Is it possible to not allow the unchecking of features in the Feature Selection tree when in Maintenance Mode?
The reason is that this is a bit confusing to the user. Say we have 5 features and features 1 and 2 are already installed. When the user goes into maintenance mode they may say... I only want to install feature 3, so they uncheck features 1 and 2 and check feature 3. You see what's going to happen... features 1 and 2 are going to be uninstalled and feature 3 is going to be installed!
I think I would prefer not to let users uninstall from here.. they should got to ARP as they are accustumed to doing. I tried setting 'Remove' to No on the package, but then they can't install all the packages by uninstalling the Suite from ARP.
Another alternative would be to make the feature 'Not Visible' if it is already installed, but the only choices are Yes or No. Any ideas?
Thanks.

[MichaelU]

Hmm. I don't think we have a way to do this today. It sounds like your core observation here is that the checkbox is a bit confusing. You're worried that one of your users will interpret the checked box to mean that it's going to reinstall (perhaps repair?) the feature during maintenance, and want to uncheck it to save some time. Unfortunately it will just cost time because that removes the feature.

I think we need to come up with a better way to represent things. I'm partial to the checkboxes because when you know what they mean, it seems simpler than Windows Installer's weird drop down. But when you don't know, I can easily understand being confused. And in the mean time, for your particular case, would a specialized page for maintenance which allows you to click buttons or checkboxes specifically to install a feature be more what you're looking for?

[rguggisberg]

Thanks Michael,
Your observations are correct. Is there anything planned for a future HF or SP that might address this? I don't have any ideas as to what I might do about it until then.

[MichaelU]

How complex is your feature tree? Does it make sense to make a page with install/uninstall buttons for each feature? These buttons could change the request state of the feature, and probably enable/disable based on the current request state, or something like that. Alternately hide and show certain labels that would summarize what will be done.

[#5]

If you want to control the feature selection, you can use selectiontree control in the customsetup dialog.

It can be conditioned using property “MsiSelectionTreeSelectedFeature” & MsiSelectionTreeSelectedAction.

An example is given below


First row, I am adding a feature “A”, if user selects to uninstall feature “A”, then it sets A to addlocal. It means it wont allow the user to uninstall.
Second row, CustomSetup1 is clone of CustomSetup, I use this to overcome the refresh issue.

[rguggisberg]

lambertpandian,
Your response was relevant for a Basic MSI project... this is a Suite project. Still hoping Flexera comes up with something in next HF/SP.

[rguggisberg]

Michael,
Will the next release address this issue?
We have concluded that it is confusing to allow modifications to a Feature Selection Tree that cause some features to be removed and others to be added in one operation. So we would like to disable the unchecking of boxes for features that are already installed (user should uninstall via ARP). One can almost accomplish this by setting the Eligibility Condition to the opposite of the Detection Condition. This still allows the user to uncheck the box, but it does not actually do the uninstall. However, this is not a solution because then it does not uninstall from ARP when you uninstall the Suite.
Thanks.

[rguggisberg]

Michael,
Will this be addressed in the next release (see the post above)?
My feature selection tree consists of 5 features and 1 sub feature. Would really rather not have a separate page for each as you asked about in one of your previous posts.
Thanks.

[MichaelU]

I don't think I have a clear idea what would replace the current option, so as of yet, I don't think it'll be "solved."

But I didn't mean to create a page per feature. You could create one page with buttons for each feature. Something like this, where each Install or Remove button sets the corresponding state, and is only enabled when appropriate.
[CODE] Feature X [Install] [Remove]
Feature Y [Install] [Remove]
Feature Z [Install] [Remove][/CODE]

[rguggisberg]

Thanks Michael,
I like your idea and was able to make a different 'Custom Setup' screen for Maintenance to use in place of the InstallationFeatures screen when in Maintenance mode. On that screen I have 2 columns of checkboxes... 1 For install and 1 for Remove. My intent is to only make the appropriate box (Install or Remove) visible for each feature depending on whether the feature is already installed or not.

To make the appropriate checkbox visible and hide the other one I set Visible for the Install checkbox to
{Binding FEATURE[FeatureName].actionState!=install
and set Visible for the Remove checkbox to
{Binding FEATURE[FeatureName].actionState==install

I set Property to
FeatureName.actionState==install
That gives me the look and checkbox behavior that I want.

Problem:
How do I populate the Feature Selection tree so that it performs the requested install/remove?
When you click install it moves forward to InstallationProgress screen but does not install or remove.

I tried setting Action to
{SetProperty FEATURE[FeatureName.].actionState=install}
But that makes the screen change immediately. So if I click the Install box... because of my Visible condition the Install box is now invisible and the Remove box is visible.
Most likely there is a simple solution.... but is elusive!
Thanks Again.

[MichaelU]

Hmm. I probably would have used conditions on Enabled instead of Visible, but same idea really. The Install button at the bottom is special in that it will always try to start an installation. Other buttons you can just do actions like you set up here. Or they can kick off install by including an {Install } action. And of course once one thing kicks off the install, you're done with asking questions. I wonder if your scenario would be better of with radio buttons and a third column (leave alone). But I don't think I really understand your current question well enough to answer.

A previous edit asked about the difference between {Binding property==value} and {SetProperty property=value}. On a pushbutton it's almost the same thing. On a check box or radio button it changes whether the checkbox will reflect the change. For instance, a check box with Property {Binding P==1} and Action {SetProperty Q=1} will set both properties on check, and unset P on uncheck.

[rguggisberg]

Thanks for the info Michael. I think I want to stick with checkboxes instead of buttons so that the user can change their mind and uncheck things they just checked.

To explain what I am trying to accomplish...
The Flexera supplied default 'InstallationFeatures' screen is fine for a new install. What I am trying to do is avoid confusion when using that screen for Maintenance.

Say we have 5 features and features 1 and 2 are already installed. When the user goes into maintenance mode they may say... I only want to install feature 3, so they uncheck features 1 and 2 and check feature 3. You see what's going to happen... features 1 and 2 are going to be uninstalled and feature 3 is going to be installed, which is not what they wanted. Furthermore, if they make changes to their original checkboxes, it is easy to forget the states they were in when they started.

So I made a new 'MaintenanceFeatures' screen that has 2 columns... 1 for install and 1 for remove that I use in Maintenance mode. So you can install and/or remove, but at least it is clear that you are going to do only the checked operation for each feature. Only 1 of the 2 columns is visible (Visible is preferred over Enabled in this case because if I use Enabled both boxes are shown and I only want 1 of the 2). That part is fine. It looks right and the check marks stay as the user checks a box and are cleared if they change their mind and uncheck it.

What I have not figured out is how to make the selection information available at run time. It just blazes through the InstallationProgress screen as if there is nothing to do. So I need to know what property(s) to set so that the requested install/remove behavior will be triggered when the user clicks Install.

I tried setting the Property for each checkbox to
FeatureName.actionState==install
or
FeatureName.actionState==remove
But that seems to have no effect.
Edited 1/2/2012 - The correct syntax is:
FEATURE[FeatureName].actionState==install
or
FEATURE[FeatureName].actionState==remove

Looking at the help for Property
Populating Combo Box and List Box Controls in the Wizard Interface (help "topic: SteUIContentProp.htm)."
it would appear that the syntax should be
FeatureName.actionState\rinstall or \rremove
I tried that too with same results.

I am stuck! Any help is appreciated.
Thanks Again.

[rguggisberg]

Michael,
Well I thought I was on to it... but I guess I am going to have to call for reinforcements 🙂 I can get some behavior out of it.... but just can't get it right.

Earlier you said that putting
FEATURE[FeatureName].actionState==install or remove
in Property would cause the appropriate action.

The problem with doing that is that then the checkboxes appear/disappear immediately when you check a box. I have been trying to somehow save the FEATURE[FeatureName].actionState in a new property in the Properties view so I can use that property for Visible. Evidently that is not the right thing to do or I am not doing it right.

Any ideas are appreciated.... ones that work are REALLY appreciated 🙂
Thanks

[rguggisberg]

I am slowly getting there. I can get the look I want or the behavior I want. Struggling to try to get both!

To keep the checkboxes from swapping when I click on them (because the property changes) I have added a CBnxxxxState property that is initially 0. When a CB is checked I set the property to 1. Now I want to set visibility to something like this:
{Binding FEATURE[FeatureName].actionState==install | CB5RemoveState==1}
or
{Binding FEATURE[FeatureName].actionState==install} | {Binding CB5RemoveState==1}
But that is not working. Is it possible to do something like this?
What is the correct syntax for THIS or THAT?
Thanks

[rguggisberg]

While it might be useful to be able to combine properties in a comparison, it would be simpler if there was another property that is what I need. I am using
FEATURE[MyFeatureName].actionState
My problem with using that for 'Visible' is that it changes as soon as the box is clicked. What I really need is a property that specifies the current installed state of the feature.
Is there another property similar to FEATURE[MyFeatureName].actionState that would be appropriate?
Where would I find a list of such properties?
Why is that one not listed in "Suite Property Reference" in Help?

[MichaelU]

Sounds like you've been looking for FEATURE[name].installState - see this older post ...

These aren't exactly properties, which is part of why we omitted them before. But we should probably document them going forward.

[rguggisberg]

Sweet... or Suite 🙂
Thanks Michael... I knew you would have the answer.
That's exactly what I needed. Are there any others besides
FEATURE[FeatureName].installState
and
FEATURE[FeatureName].actionState
that we should know about?

For anyone else reading this... It seems that you can use "install" or "remove" for
FEATURE[Server].actionState==
but you need to use a numeric value (I used 0) for
FEATURE[Server].installState==

Thought I had a problem uninstalling one of the packages, but it turns out my 'Remove EXE Command Line' got removed!

[MichaelU]

Here's the full list today. I don't think the others are likely to be useful; they're just used behind-the-scenes for the feature selection dialog that shows the extra information.

• FEATURE[name].actionState
  
• FEATURE[name].installState
  
• FEATURE[name].displayName
  
• FEATURE[name].description
  
• FEATURE[name].cost
  

[bw1234]

Hey rguggishberg. I'm wondering if you ever had a resolution to your question about binding multiple conditions to a visibility property.

I have a Suite installer that shares dialogs between the features. For example, FeatureA and FeatureB need to capture the same inputs, so I want the dialog to be visible only when FeatureA or FeatureB is selected.

I would like to use something like:
{Binding FEATURE[FeatureA].actionState==install OR FEATURE[FeatureB].actionState==install}

Were you able to get this type of conditional statement working?

[rguggisberg]

bw1234,
No I did not. In my case I found out about FEATURE[name].installState, which replaced the need for me to combine FEATURE[name].actionState with something else. I used "|" for "OR" when I was trying, but it did not work. I see your point and I agree that there will be cases where binding multiple conditions would be handy. My suspicion is that it is not possible at this time or Michael would have mentioned it. He may reply further after seeing this post.

It would be nice to have a list of what the possible values for installState and actionState. Where would I find that?

[MichaelU]

Unfortunately rguggisberg's right - boolean algebra like that is not available at this time. We're exploring some syntax alternatives that will allow more expressiveness, but I have no timeframe on that yet.

The install state is either 0 or 1 (not installed or installed, respectively).

The action state is one of (empty), install, or remove. I think we still have to add repair to that list.