I'm experiencing some strange behaviour in my setup. My initial problem was that MSI45 didn't get installed even if it was deteced correctly as missing prerequsite. I've inserted a Runtime Debug: Show variables into the setupmsi45 and it shows MSI45 as FALSE, but the following If statement
If Variable MSI45 Equals FALSE
doesn't lead to executing the code inside the If ... End. I cannot see, what I might try to change this behaviour. I have the suspicion that internally another variable is checked.
Now I've tried to set MSICode Statement Identifiers to dynamic. Additionally I've changed the name of the variable MSI45 to MSI45CHECK. When I compile my setup now results in the following message:
Obviously the compiler is mixing the variables MSI31 and MSI45. Is there any way to reorganize variables and to get this fixed?
I've used the latest version of IA9. The setup was developed completely in IA9, there was no upgrade from a previous version.
But tonight I've found the problem! The translation file was out-of-sync with the script and inside the translations are also the names of my variables! There was (sometimes) MSI45CHECK translated with MSI31 ... (believe me, I haven't made this translation).
My question is: who needs a translation of the names of variables?!? That's a pretty dangerous "feature"?!
LOCMODE: Controls how localizations are applied at runtime. This compiler variable has impact on script localizations only, and has no effect on dialogs or shared strings:
If VARSONLY, the only localizations that are applied to a running setup are those for Localization Variable commands, even if other commands have been localized. This helps prevent incorrect and/or unintentional translations of other script commands from breaking a localized setup at runtime.
If NEWONLY, localizations for all commands are applied to a running setup, except commands which have not been localized yet and remain with older default strings, protecting elements which may have since been updated in the script. This helps prevent default values used in unlocalized commands from overwriting the newer values which may have since been changed in the script.
Note: For this option to have effect with old setups, add the file translations.Original from your translation export folder to your setup as a support file. New setups will automatically have this file.
With any other value, all localizations are unconditionally applied.
Sounds like you want NEWONLY.
Candice Jones
Install[b]Aware[/b]
[i]Home of The Next Generation MSI Installer[/i]
Get your free copy today - http://www.installaware.com/
I probably want to translate "Main_Pool", but for what reason should anyone want to translate DBNAME? That's pretty dangerous.
I'd suggest an option to switch off that behaviour, so that only the content of a variable is written to the translation file, but not the variable itself.
I'm totally agree with you. Because of this functionality i've lost almost 40% of develop time because of this. So now after tons of bloodshed i'm using just VARSONLY value. I've moved all localizations to Localized variables. So if i need some value to be translated, i just declare a localized variable. Same for the feature names and their descriptions (You can read my post, it's sticky, about Feature name as a localized variable).
Same problem with Translator for the IF statements. Each Yes statements it translates to localized variants (in my case into Russian). But when i check for equality the value read from registry (which is equal "Yes") i have always a FALSE result, because of such "translation".
So now i'm using VARSONLY value.
But before using it, you should move hundreds of strings from MessageBoxes from each Prerequisite to Localized strings to have them translated.
To IA stuff:
Frankly, i was disappointed with this mechanism. Translating every word that you meet inside the code, imo, is not very cool. At least it would be nice if IA would give some considerations before using Translator (and the translation overall) because almost half of my time of debugging was spent struggling with such behavior and results. Indeed, after walking through all of this, i have "Rocket Science" now. According to the
PS. As a suggestion it would be cool if all strings from message boxes of Prerequisites would be moved inside localized strings, it would save much time of the rest of the world, i.e. your customers. Thanks for the understanding.
PPS. It would be good if IA version 10 would not use a "new kind of bike with 20 wheels". A classical bike with two wheels would be sufficient. A table with 2 columns (name it wheels). The first column (wheel) is the literal ID of the string (example: ID_PREREQ_MSI45_SETUP_FAILURE_MESSAGE). One ID will take role in each language where it will be specified. The second wheel (column) is the localized string itself containing translated variant of the message.
I know the last paragraphs was a bit emotional, but believe me, i'm not the only one who think the same way.
