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
Related
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.
I need to add a dialog box that would pop up during complete uninstall (not major upgrade) right after the confirmation ("Are you sure you want to uninstall this product?") dialog. This dialog would prompt the user to answer a question and based on the response, set up a property that would be used in the condition for the RemoveRegistryKey element (i.e. it will remove a registry key only if the user selects an option to delete the key).
I have an idea how to add a dialog to the install sequence (I am using a modified WixUI_InstalLDir sequence to which I added a custom dialog I need during installation), but I can't find any references that would explain how to add a custom dialog to an uninstall sequence. It would be even better if I could modify the uninstall confirmation dialog, so the user would see one dialog instead of two. An the key thing would be to be able to set up a property that could be used in the component condition.
Is this possible? Are there any examples how to do this?
This is against Microsoft design guidelines. Add/Remove programs calls the uninstall with a silent UI argument and the UI sequence is never processed.
The only place you can author UI during an uninstall is a "change" or "maintenance" UI experience where they select Repair | Change | Remove and on Remove do your UI. But you'd have to lock down the Remove buttom and force them through this path. Also realize they could call msiexec /x /qb from the command line.
Bottom line is Microsoft made this choice to make the uninstall process simple and easy for the user. As for removing the registry key, Microsoft would say that you should leave user data on uninstall.
I've got some verbose text that's being truncated on my WelcomeDlg:
Clearly there's loads of room in the dialog for the extra lines of text, but the text box is too small. How can I make it larger?
You can take a look at the source for the WelcomeDlg to see what is happening. The text you are displaying is the <Control Id="Description" .... />, but you'll notice there is also another text field below it for describing a patch if it is being applied.
You can customize the WelcomeDlg by following the instructions in the last couple of section of this page in the manual. Here are some quick steps:
Copy the fragment for the WelcomeDlg into your own project from the Wix sources.
Change the Id attribute of the Dialog tag to be unique. You can then make any changes to the dialog you need (such as making the patch description field smaller and the description field taller).
Copy the fragment that defines your UI sequence from the Wix sources into your project. If you were using the WixUI_InstallDir sequence you would copy this file.
In your custom dialog sequence file you need to change the Id attribute of the UI tag to be unique and any references to WelcomeDlg to the Id you put on your custom WelcomeDlg.
In your main package change your <UIRef Id="..." /> tag to reference the custom dialog sequence.
Not to dismiss your requirement outright, but I would keep in mind that the attention span of a user running an installer is about that of a 2 year old. They likely won't read whatever you are putting there in the first place. Same goes for that EULA that management always wants to make sure the user scrolled all the way through before being allowed to click I Accept.
I follow a minimalist approach when creating installer UI. Next, Next (if needed), Install, Finish. Still don't quite like the Install Finish pattern but some do.
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.