Nevermind...this won't work. I can't condition a UI segment on whether or
not a component will be installed since CostFinalize will not have been
invoked at this point. However, I guess I could just append my guid onto
the property (myprop.[guid]) and condition the UI off of that?
On 2/8/07, Levi Wilson <[EMAIL PROTECTED]> wrote:
Would it be bad to check the existence of one of the components then from
the merge module from _outside_ of the merge module? For instance, if I
have one of the components (component1.[guid]) condition of two properties
contained in my merge module, and I have some UI outside of the merge
module, can I condition some text to be displayed depending upon whether
component1.[guid] is being installed? Is that a bad practice?
On 2/7/07, Bob Arnson <[EMAIL PROTECTED]> wrote:
>
> 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
