Levi Wilson wrote:
Alright, I'll try to tread slowly through this one... I have a merge
module that has a settings file that is packaged with it. I have a
file search setup within my merge module that sets an "OLDSETTINGS"
property. Now, here is where things get fuzzy. IF the OLDSETTINGS
exist, the module will not install the default settings (packaged with
it), but instead copy the old ones over. If the OLDSETTINGS do NOT
exist, it will use the default. The problem that I am running into is
that I have a UI page that has a static text element that will display
to the user information about the "default" settings (when they're
used). Now, since the Properties from the merge module are
modularized, the UI can't access that property. So, if I suppress the
modularization to get rid of that, then when I <Condition /> my
<Component /> based upon the OLDSETTINGS property, IT gets modularized
(even though I don't want it to). Has anyone ran into this situation
before? Any help would be greatly appreciated. Please let me know
if more details are needed.
Short answer: Merge modules aren't spec'd to support what you're looking
for. They should be self-contained, so when they're merged into a
feature, its action state determines whether their components get installed.
One option I've seen teams use is to build a merge module from a
.wixobj/.wixlib. The "internal" product consumes the .wixobj/.wixlib but
the redistribution is the merge module.
--
sig://boB
http://bobs.org
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
