I'm not sure exactly what you want here; it sounds like you're describing a use case for radio buttons instead of checkboxes. If you need to allow one, the other, or none, consider three radio buttons. However setting the check boxes' Property setting to different values (MyProp==value1 and MyProp==value2 respectively) may yield the mutually exclusive behavior you desire.
As for conditionally disabling one of them, see the Enable setting of your check box or radio button. I'll have to get back with more information on what you can use here to implement the 32-bit vs 64-bit OS condition.
Oh, it sounds like I misunderstood. Are you trying to implement this in the feature tree (InstallationFeatures page)? While there is something you can put in the XML to make a feature unselectable, it currently it's an all or nothing option - you can't specify a condition for this.
I think I would suggest an alternative approach, along the lines of an InstallationType dialog where you have multiple buttons that branch your installation. For example you could have an "Install the 32-bit version" and an "Install the 64-bit version" command link button, and disable the latter on a 32-bit system. Would this suit your needs? If so I'll try to work out how we can make that possible.
I was looking to implement this for an upcoming release, but it turns out we actually do have something in place you can use, so long as you don't have to tie more than one feature to a button. So for what I understand of what you want to do, create two command link buttons. Set the text and note appropriately. Then specify a Property setting on each button along the lines of:
FEATURE[feature name].actionState==install
where feature name is replaced with each feature's name. Then when the button is clicked, the associated feature will be set for installation.
If you'd rather put these on checkboxes and have them enable and disable like you mentioned before, specify the Property setting as above, and also specify an Enabled setting similarly:
where other feature name is the name of the feature that should cause this feature's checkbox to be disabled. Watch out though; with this condition, if both features get enabled, neither can be disabled.
What is the difference between doing FEATURE[feature name].actionState==install for Property versus doing {SetProperty FEATURE[feature name].actionState=install} for Action?
It is a bit annoying that the syntax is not consistent. I REALLY would have expected that there would be more documentation available about Suites from Flexera by now. I don't think that anyone can argue that those of us that have used the Suite feature have struggled with A LOT of trial and error! Yes, yes, I know... standard answer is read the blogs. And when that does not contain the info you need?????
Oh, whoops, here's the question I thought was asked elsewhere. Got my email notifications miswired. 🙂
{Binding P==V} functions differently on, say, a check box. It shows the check box as checked if the property P has the value V. Clicking the check box when checked will reset the property to empty; when unchecked, it will set the property to V. On a pushbutton, it will merely set P to V whenever it is clicked.
{SetProperty P=V} as an action works just like the pushbutton case, although I'm unclear off the top of my head if it also fires when the radio button is clicked to clear the check box. Note that, particularly in a check box or radio box, you can have both; {Binding P==V} and {SetProperty Q=R}, so two properties can get set in one click.
