In our installer the user has the option to install a
SQL Server database by going into Custom Setup and
selecting this feature. If they choose to install it,
I need to display a dialog with the SQL Server name,
username & password etc.
I am linking with the WixUi_Mondo library. In order
to get my SQL Server dialog to display after the
"Custom Setup" dialog, I created my own "Custom Setup"
dialog and then set the
"WixUI_SetupTypeDlg_NextCustom" property to point to
my new dialog. So, now all i had to do was to ensure
that when I pressed the 'Next' button on my custom
setup dialog, it would either go to the standard
pre-install dialog (VerifyReadyDlg) or to my own SQL
Server dialog depending on whether the user chose to
install the Sql Server database. To do this, I am
checking the feature state as follows:
Things work fine if I go through all the installer
steps in one go and don't press 'Back' anywhere. But
things don't work as they're supposed to if I go
through it in a certain order. For example:
1. I select "Custom" setup type
2. On the "Custom Setup" screen I DON'T select the SQL
Server db and press next (This takes me to the
standard pre-install screen).
3. If I then go back to the "Custom Setup" screen and
now select the SQL Server Db feature and press next,
it does not take me to my SQL Server screen.
Hope that explanation makes some sort of sense. So,
what seems to be happening is that the feature state
is not evaluating to '3' when i go _back_ to the
Not sure what to do. Any ideas really appreciated...
How much free photo storage do you get? Store your holiday
snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com
> In our installer the user has the option to install a
> SQL Server database by going into Custom Setup and
> selecting this feature. If they choose to install it,
> I need to display a dialog with the SQL Server name,
> username & password etc.
This is the exact scenario that I want to write a compiler extension
for...Conditionally showing/skipping dialogs is such a pain...
I don't see anything obviously wrong. Two suggestions:
- Check a verbose log for property-setting messages; MSI 3.1 verbose logs
include a message every time a property changes, so you can see when th
WixUI_* properties are set.
- Reorder your Publish elements so that the the property-set events come
before the NewDialog event.
This is exactly what I've been looking for. The problem is that the sequence of dialogs
between Welcome and Verify has no "fixed" points, i.e. any of the dialogs inbetween my not
be present under some circumstances. What I did in my case is got rid of Setup Type
dialog (Typical/Custom/Full). Every setup I have is Custom and hence the Customize dialog
is always present. Why? Because Typical = click through Customize. Full is implemented
easily by adding a pseudo-feature "Everything" as parent to all subfeatures.
After Customize I can have my own custom dialog(s). I only care about first in the chain
and save its name in the property. This property can be also set to VerifyReadyDlg
meaning no custom dialogs of my own. Thus from VerifyReadyDlg going back can be to either
what property holds (always go back to the first custom dialog in a chain) or, if property
value is VerifyReadyDlg, to the CustomizeDlg (it's always present in my setups).
This "standard" UI simplified my life tremendously.
Oh, and I always have License dialog, so it's a stable point in the chain too. What
setup is going to be without a license agreement unless it's for your personal use (in
which case clicking through blank agreement is no big deal).
Friday, September 16, 2005, 10:15:50 AM, you wrote:
> This is the exact scenario that I want to write a compiler extension
> for...Conditionally showing/skipping dialogs is such a pain...
RE: Re: Showing dialog based on feature selection
> This is exactly what I've been looking for. The problem is
> that the sequence of dialogs
> between Welcome and Verify has no "fixed" points, i.e. any of
> the dialogs inbetween my not
> be present under some circumstances.
Yup. I've had to do setups with several conditional dialogs and it's a MAJOR
pain. After a certain number (I'm thinking one<g>) your sanity will
appreciate an external UI handler.
> What I did in my
> case is got rid of Setup Type
> dialog (Typical/Custom/Full). Every setup I have is Custom
> and hence the Customize dialog
> is always present. Why? Because Typical = click through
> Customize. Full is implemented
> easily by adding a pseudo-feature "Everything" as parent to
> all subfeatures.
Personally, I always choose Custom on those dialogs, so I tend to get rid of
them too. (Hence WixUI_FeatureTree.wixlib.<g>)
The compiler extension is just a glimmer in my head at the moment, but I'm
confident that we can express conditional Next/Back behavior in XML and spit
out the right control events. As soon as that supply of 26-hour days comes