When you have more than two possible sources for a property's value, then you
will need some intermediate properties.
Here's how that works: At the start of the sequence, a property may have been
initialized with a variable either from the property table or from the command
(or, in the case of the execute sequence, the ui sequence). If a value wasn't
set (or in the case of the command line or ui sequence, was removed), then it
will start out not set (not in the list of properties with values).
Any attempt to set a property to a blank/empty value will remove that property
from the property list (so, reading a blank value and assigning that the
property will clear that property's value).
The SetProperty element schedules a custom action that sets a property to a
formatted value. If the condition is false, then the action will be skipped
(like any other action). At the time that action runs, if the condition is
true, it will set the property's value to the action's value. Walk the sequence
in order and see what is happening (I find it helps to open my MSIs in Orca to
"walk" the database, much like I look at source code "walk the instruction
flow" to see what I expect to happen as I write down what I expect all the
variables to be. Helps a lot when debugging some strange occurrence in my (or
anyone else's) code).
Now that you have more sources, you will need to catalog them, and set them one
at a time. However, given that it is easier to detect a property that hasn't
yet be set than it is to detect a property that has its default value, turn
your problem around.
First detect the possible values for your property from wherever they may be
(into intermediate properties). Then, pick the one that always overrides all
the rest of them, and set your property to that value. If your property is
still "empty", then set it to the next most important version of itself, etc.
The last one you will attempt to set will be the default value. Each time, the
condition for setting the actual property will always be the same: "Not
<PropertyName>".
An optimization I always do is I use the actual property name when setting the
first value (reduces the number if intermediate properties I need AND the first
assignment doesn't need a condition since I will always attempt it). If that
value is not the command-line, then I always reserve the "public" name that the
users see for the command-line and use a different "internal" name for the
actual property.
Hope that helps. Look up conditions, sequence tables, and properties on MSDN
for Windows Installer to understand more. Also, there's a great book out, a
great tutorial, and lots of information accessible via Bing/Google/etc., as
well as this user list.
-Blair
> Date: Mon, 6 Jan 2014 07:48:21 -0800
> From: tr...@outlook.com
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Unable to override SetProperty value with Edit
> Control value
>
> Thank you - that worked but I could use some help in understanding how/why.
> How does setting the condition "Not PROPSERVERHOSTNAME" force the property
> to be updated to the user override value on the backend when the xml file is
> updated?
>
> There's also one other kink I'm trying to figure out in regards to my
> original question. I did simplify my code in the original question, but
> what I'm actually trying to do is set a default value for a property, allow
> the user to override that property value then store the value in the
> registry and then load the property on subsequent upgrades. If I include
> the condition you specified, then my Registry key now will never load
> because PROPSERVERHOSTNAME already has a value of "Sample". Any thoughts on
> how I can get this to work?
>
> <Property Id="PROPSERVERHOSTNAME" Value="Sample" Secure="yes"/>
>
> <Property Id="PROP_REG_APPSERVER_HOSTNAME">
> <RegistrySearch Id="REG_APPSERVER_NAME" Root="HKLM" Key="$(var.RegPath)"
> Name="APPSERVER_HOSTNAME" Type="raw"/>
> </Property>
> <SetProperty Id="PROPSERVERHOSTNAME" Value="[PROP_REG_APPSERVER_HOSTNAME]"
> After="AppSearch">Not PROPSERVERHOSTNAME AND
> PROP_REG_APPSERVER_HOSTNAME</SetProperty>
>
>
>
> --
> View this message in context:
> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Unable-to-override-SetProperty-value-with-Edit-Control-value-tp7591569p7591593.html
> Sent from the wix-users mailing list archive at Nabble.com.
>
> ------------------------------------------------------------------------------
> Rapidly troubleshoot problems before they affect your business. Most IT
> organizations don't have a clear picture of how application performance
> affects their revenue. With AppDynamics, you get 100% visibility into your
> Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
> http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
> _______________________________________________
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
------------------------------------------------------------------------------
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100% visibility into your
Java,.NET, & PHP application. Start your 15-day FREE TRIAL of AppDynamics Pro!
http://pubads.g.doubleclick.net/gampad/clk?id=84349831&iu=/4140/ostg.clktrk
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
