Is it possible to do this:
* Assume the user of the msi file is doing a custom
install (ie looks at the feature tree).
* If the user wants to install Feature A, Feature B
should be marked as not to be installed and vice versa?
Apperently, the Feature doesn't have a condition field.
So I fear this isnt possible?
Regards,
Thomas
"Thomas Have" <tho...@povtal.org> spake the secret code
<239601c1d57f$9b076300$3bef2ecf@TKMSFTNGXA10> thusly:
>Is it possible to do this:
>* Assume the user of the msi file is doing a custom
>install (ie looks at the feature tree).
>* If the user wants to install Feature A, Feature B
>should be marked as not to be installed and vice versa?
So if I understand you correctly -- you have two mutually exclusive
features and you want the user to select one or the other, but not
both?
You can't do this directly with the feature tree, but you could do it
with a custom dialog that used radio button controls to select either
A or B. In the Feature table, make the features undisplayed so that
they are not shown in the feature selection tree. Then in your
custom dialog, you can set the feature install state based on the
choice made with the radio buttons.
If you need more details, just ask.
--
Ask me about my upcoming book on Direct3D from Addison-Wesley!
Direct3D Book http://www.xmission.com/~legalize/book/
izfree: Open source tools for Windows Installer
http://izfree.sourceforge.net
> .... in your custom dialog, you can set the feature install
> state based on the choice made with the radio buttons.
Pardon the ignorance, but.....how exactly do you do that (setting a
feature's install level at runtime) ?
Sam
"Sam" <sam...@ubid.com> spake the secret code
<etpxE#L3BHA.2660@tkmsftngp05> thusly:
One way would be to have the controls manipulate properties that
are used in the Condition table to set the install level for a
feature. This is probably the easiest way.
Another way would be using the AddLocal and AddSource events with the
control to tell the installer to set features to run locally or from
source. So you can initially have the feature not installed, then set
a control event to set the feature to run locally when the control is
manipulated.
Sam
"Rich [Microsoft Windows Installer MVP]" <legaliz...@mail.xmission.com>
wrote in message news:a8ksdd$mma$1...@news.xmission.com...
"Sam" <sam...@ubid.com> spake the secret code
<um2qm5x3BHA.2660@tkmsftngp05> thusly:
>I tried the first solution you suggested and it didn't work. Apparently the
>Condition table is accessed during the CostFinalize action, which must be
>executed before starting any user interface sequence, so by the time the
>user gets to the dialog where the controls can be manipulated , the install
>level of the features has already been determined.
Ah yes, I remember this now. We took care of that by executing
CostFinalize again when leaving the dialog. We set a control event
on the "next" button that left the dialog and had it execute a
DoAction event with the argument of CostFinalize.
I was never 100% sure if that was completely valid according to
strict Windows Installer rules, but it did work for us in our install
and was recommended through the IS newsgroups as at the time we were
using their product.
>As for the second one, could you provide more details? I am new at this
>thing and I have not found anything useful about Windows Installer Events in
>MSDN. There are definitions and a few rules, but I couldn't find an
>explicit example of how to set up events the way you are suggesting.
A control can publish events bia the ControlEvent table. The
AddLocal and AddSource events are events whose argument gives the
feature to add.