I made an installer using wix burn.
I used the standard bootstrapper with Hyperlink license theme.
I don't want to display the EULA checkbox on upgrades. Once accepted one time, I don't want to show it again, or at least auto select it.
To achieve that, I customized the bafunctions.dll and wrote some code in OnDetect(). After a given condition is match, I set the variable EulaAcceptCheckbox = 1. I know that this is the variable name corresponding to the EULA checkbox because I inspected the log of the installer before making this changes.
After making all the modifications, I know my logic is working because I see the following lines in the log:
[1510:1410][2015-11-17T19:01:04]i000: Running detect complete BA function
[1510:1410][2015-11-17T19:01:04]i000: Setting numeric variable 'EulaAcceptCheckbox' to value 1
But the checkbox is not displayed as checked. I tried to set 'EulaAcceptCheckbox' in OnDetect() and also in OnDetectComplete(): no luck.
I also tried to set LicenseUrl="" and WixStdbaLicenseUrl="" but that does not work either.
I have already used bafunctions.dll to do some checkbox customization in another installer. It seems not to work with the EULA checkbox only. What's wrong with my approach?
There seems to be no solution for this.
Related
I am trying to write a simple windows installer that has to write some fields in a .ini file if a feature is enabled. On the lower level, this is if a specific property is set from a checkbox.
I have been googling for days, but neither the internet nor the docs seem to be of help. Can anyone point me in the right direction regarding having optional fields in a section?
All changes to resources on the machine (dir,file,reg,ini and so on) are associated with components. Components are associated to features. So if a feature is being installed, the component is being installed and therefore the resource is being installed.
So you nest an IniFile element underneath a Component element.
https://wixtoolset.org/docs/v3/xsd/wix/inifile/
Checkboxes controll a property. Checked it has a value you specify. Unchecked it has no value.
There's also a little problem that Windows Installer doesn't remember property values for subsequent transactions and that the IniLocator table can only read ini files from the Windows folder.
You might want to store this value in a registry key also that way you can read it back in as part of the remember pattern.
Find my email address and hit me up. I'd be happy to walk you through it as an excercise.
I was trying to change the default MsiRMFilesInUse dialog box provided by restart manager used in wix toolset. Basically I want to localize the default message in the dialog box since it is not getting localized by windows.
I found this answer (https://stackoverflow.com/a/46462452/14162315) which explains the steps of making the custom dialog box instead of normal one. A custom dialog box could help me in localizing the message.
I tried the above steps but I am getting the error - Duplicate symbol 'Property:WixUIRMOption' found. This typically means that an Id is duplicated. Check to make sure all your identifiers of a given type (File, Component, Feature) are unique.
I thought that I have to change the property id of WixUIRMOption also to some custom value to mitigate the error, so I changed it to Custom_WixUIRMOption. It compiled successfully after this change but the dialog box is not coming at all after this change.
link to source code of default MsiRMFilesInUse.wxs - https://github.com/AnalogJ/Wix3.6Toolset/blob/master/RC0-source/wix36-sources/src/ext/UIExtension/wixlib/MsiRMFilesInUse.wxs
you should be fine if you provide a localization for MsiRMFilesInUseText.
<String Id="MsiRMFilesInUseText" Overridable="yes">Translated text</String>
See how the dialog is implemented:
https://github.com/wixtoolset/wix3/blob/develop/src/ext/UIExtension/wixlib/MsiRMFilesInUse.wxs
See how wix ui is translated:
https://github.com/wixtoolset/wix3/blob/develop/src/ext/UIExtension/wixlib/WixUI_en-us.wxl
I'm using WIX 3.0
After I install my product, I can run installer again and remove or repair my product.
How to specify different text on exit dialog for repair and remove?
I used "Installed" property, but it has the same value for repair and remove
Do you have any ideas?
Thanks in advance
You'll have to modify the ExitDialog.wxs for this (taking it from WiX sources and including to your project).
Take ProgressDlg.wxs as an example. It contains several pairs of controls, prefixed with 'Text' and 'Title', for instance 'TextInstalling' and 'TitleInstalling'. These pairs of controls are located at the same positions on a dialog, but are conditioned differently. For instance, 'TextRemoving' and 'TitleRemoving' are shown when WixUI_InstallMode='Remove'. Hence, setting WixUI_InstallMode to 'Remove' at the beginning of uninstall shows "Removing files", etc. on a progress dialog.
You can use this technique for other dialogs as well.
Thanks for update, Yan.
My problem was not how to change some text, but how to know what action was performed, remove or repair.
I don't know if this is good solution, but I used custom action and set the all text I need in the properties. The custom action runs with condition $MyInstalledComponent=2, which means that component is removed and is TRUE only on remove, but not on repair
I have an msi (authored with WIX) that has a check box bound to a custom property (call it MY_PROPERTY). I would like to run this msi from the command line, specifying 0 (unchecked) or 1 (checked) for this property. My script will determine the appropriate value (based on the environment) and inject that value into the msiexec command line. My command line looks something like this:
msiexec /i my_installer.msi MY_PROPERTY=$value
Where $value is 1 or 0, depending on the environment. The problem is that no matter what value I supply for MY_PROPERTY at the command line, the check box is always checked (and the property will always be set to 1). The only way to make the checkbox unchecked is to not specify the property (leave it undefined). It should be noted that this behavior occurs regardless of whether or not the UI is showing (adding "/quiet" to the above command line doesn't change this behavior).
This msdn post seems to indicate that this is a known "bug" in windows installer (or more accurately, whatever authoring system wrote the msi). A post-build msi hack is proposed as the solution. I'm wondering if anyone has encountered this issue and come up with a better workaround/solution. Thanks!
Update
I see three solutions to this problem:
From #Damien, have the wrapper script not pass the property to msiexec when its value is 0. This makes the script more complex and would probably prevent me from being able to override the value of a check box that defaults to "checked".
From #Michael Urman, add a custom action that clears the property if its value is zero. This makes the msi more complex, and I would have to add such a custom action for every check box in the UI.
Another idea is to simply disallow the use of check boxes in our msi installers, and use radio boxes or drop-downs for "true/false" questions instead. While this restricts the UI options for our installers, it woudl allow the wrapper scripts to remain simple, and does not require custom actions to "hack" the properties.
I'm currently leaning towards option 3, although option 1 is probably the best answer to my original question. Any thoughts?
This is how it is "supposed" to work - basically, the property doesn't exist until a user checks the checkbox, then it is "set" (exists). So if you want to do a custom action when a checkbox is checked, you test for the existence of the property as a condition for running the custom action, instead of checking for the value that the custom prop is set to.
I think the best way to handle this from the command line is what you have already mentioned: if you want the checkbox to be selected, specifiy the custom prop on the command line, otherwise, don't and the checkbox will not be selected.
As you've discovered, checkboxes are true (checked) when the property is defined (non-blank) and false (unchecked) when the property is undefined (blank). It sounds like you need to convert an environment 1 or 0 string to a checkbox true/false, where the 1 or 0 is passed in at the command line. Try using a set-property custom action that sets your property to {} (blank) with a condition of when the property is already "0". Schedule it early in both the Install UI and Install Execute sequences.
Late Update: Regarding the need for multiple custom actions to handle this for multiple checkboxes, you have a choice. You can either create multiple set-property actions (benefit: easy to tell what they're doing; cost: many of them), or you can create a single code-based custom action which walks the Checkbox table for a list of properties to convert from 0 to blank (benefit: one action; cost: poorly documented, custom code). A secondary advantage to the latter approach is that you can handle unusual Value settings, such a check box that should set the property to 0 when checked.
Let me be upfront I am novice with WiX. I have a custom dialog CustomSetupTypeDlg.wxs that changes the Typical/Custom/Complete to Desktop/Server/Suite. It sets WixUI_InstallMode to InstallDesktop, InstallServer and InstallSuite appropriately.
I need to have the user browse for an installation folder depending upon what feature is to be installed. If InstallDesktop or InstallSuite is selected the user has to select two different paths for DESKTOPINSTALLDIRECTORY and SERVERINSTALLDIRECTORY. However if the install mode is InstallServer only SERVERINSTALLDIRECTORY choice should be presented.
I am uncertain on how to go about doing this.
You want to have actions in your InstallExecute sequence that display the dialogs you need. Inside the tag you provide a conditional, which, when true, causes the action to actually happen. See this tutorial, specifically section 5.3 for a list of conditionals.
I decided to simplify the project by splitting the desktop and server features into two separate installers.