Support for Hebrew and Arabic on Basic Msi Projects
Aparently in the Basic Msi project although most mirroring of the dialogs is done correctly they are minor glitches. One would be that the close button of the dialog (also the minimize and maximize buttons) instead of showing up on the left they are shown on the right for most dialogs . Is there any way to solve this or any workaround for it?
Also the progress bar still fills from left to right as opposed to from right to left. Any solutions?
I am using the IS premier 2012 evalution version of the software.
I've seen this question cropping up a lot lately in a few different fora. As far as I can tell this is a limitation of Windows Installer, as the dialog and control attributes do not map to all the possible Window styles necessary for the correct behavior. If that's correct, this is a question for Microsoft.
Also, running on a machine set to the target languge will generally work better than running on a machine that merely has support for the target language, so the behavior might be right for the end user who is running in Hebrew or Arabic.
The problem is that in the dialogs generated before uncompressing the msi and running it the X buttons and the progress bar are displayed correctly. So, at least in theory there should be a way to solve this.
Also I have tried on a system running in Arabic (this is the language we need). The problem still persists.
The dialogs you mention that work correctly are shown by the InstallShield bootstrap, and thus are not subject to the limitations of Windows Installer. You might correspondingly want to check out including the Basic MSI output in a new Suite project. Suite projects use entirely InstallShield's UI, and thus are similarly not subject to the UI limitations of Windows Installer.
Tried adding the msi execs as packages in the suite project but but it appears that the system does not work... any ideas why? Also how would the install suite project affect the dialogs used in out basic msi project?
Typically we expect .msi files to be added as MSI packages. When included this way, only the Suite interface will be shown. As for why it doesn't work, if you added them as EXE packages and didn't set up the conditions correctly, it will fail. This is covered in some more detail on the InstallTalk blog in the following posts: Mode Conditions and Defining Conditions.
It seems that a suite project does not allow for much custisation , so there appear two questions: 1. What happens to the custom actions put in the ui sequence? 2. Does the Suite installation simply launches a silent install?
When you include a .msi file in a suite as an MSI package, only its execute sequence will run. You can pass property overrides on its package's Install command line to reflect settings you collect in the Suite's wizard pages.
What limitations are you seeing while trying to customize your Suite? I'd like to help figure out if these are difficulties in us communicating what Suites can do, or currently limitations in them which we will have to address in future releases.
we have a few actions that must run in the UI sequence first of all. Second we have an extra dialog which existed in the prior pure install shield version named sdSelectFolder who's functionality we have made trough custom actions set in the ui sequence. The other action that must run in the ui sequence is an custom action that simply detects if the install/uninstall is silent (practically detecting if we have an uninstall from control panel). Outside of these my main problem is that I do not know when do the custom actions are run related to the UI sequence of the install suite...
Okay, let's back up a bit here. These are the choices you have to make: Would you rather live with MSI's RTL limitations, or use Suites? If you're using Suites, would you rather use the MSI UI (which brings back the RTL limitations), or rewrite your UI using the Suite's support?
If you're using the Suite's support (which means using an MSI package, so you're not calling msiexec /i on your .msi as an EXE package), then the UI of your MSI will not run. The Suite UI will mostly run before it invokes the execute sequence of the .msi file.
To get back to your actions, the one that detects silent is almost obsolete - it will return true unless someone invokes the .msi directly (say from the control panel if you don't suppress the entry). The other, you might want to rebuild as a wizard page in the suite. Have a control on the wizard page bound to a property and it will set a Suite property; reference it in your package's command line to pass the selected value to your package.
So if that method to detect if it is silent or not is obsolete, how do you make running an uninstall from control panel work the same as you would from the setup.exe file?
About the UI sequence it should look as close as possible to the old project made in pure install script. I understand what you are saying though... Most likely we will live with MSI's RTL limitations , but we will create a Install Suite version to make a proper assessment.
Thank you for the explaination on hos Install Suite works!
In a typical suite, you would probably choose to pass ARPSYSTEMCOMPONENT=1 to your MSI package (via its Install Operation command line) in order to hide its ARP entry. You could also bake that into your .msi file, or apply it via a transform, but command line is probably the easiest way. Once you've done that, the only way the .msi's uninstallation will typically be invoked is via the suite, using the command line of its Remove Operation. If you want to detect this separately from another case, you could always add a property to the command lines such as FROMSUITE=1 or SUITEOPERATION=Install/Remove/whatever.
Does that address what you used this custom action for, to try to detect the different ways the .msi was removed? I just don't think it applies to a Suite uninstallation scenario.
