Strange "set viariable" behaviour

[prezmer]

Hello,

I've found a problem with setting TARGETDIR Property. I would like to get something like \Program Files\Company\Product.

So I decided to modify Application Information | Project Properties | Target Folder to
$PROGRAMFILES$\Siemens\$TITLE$

But application tries to install into Program Files\ and then Ttile (without Siemens). I started debugging on MSIcode tab. Then I found something strange. Set variable doesn't set to specified value. So I decided to add extra "Set variable" block. And the other one with the same arguments works fine. Why?

Here is a screenshot with watches (slightly modified arguments - without TITLE).
Before entering first set

step1.png (19.66 KiB) Viewed 29083 times

After first set

step2.png (21.17 KiB) Viewed 29083 times

After second set

step3.png (21.77 KiB) Viewed 29083 times

[prezmer]

The issue can be resolved by removing original set variable TARGETDIR with one added manually with the same settings. Maybe something wrong with synchronisation between design and MSIcode?

[MichaelNesmith]

Try the tool here on your script:
http://www.installaware.com/forum/viewt ... 3&start=60
(pGuids-fixed.zip)

It would also be interesting if you could send us instructions that reproduce this issue.

[prezmer]

It would also be interesting if you could send us instructions that reproduce this issue.

Funny, I created another project (using ProjectWizard) and this time, target folder is set correctly, I wish I stored the problematic project file.
Anyway, If the problem reraise again, I'll protect project file and send it to you.

[ALive]

Do you use localizations for your project?

The problem could be there if you forgotten to update the translated value (inside Translator tool).
Specifying the value second time and having correct behavior makes sense, because new value (before sending files into Translator tool) has it's own virgin (un-translated) value.

Hope this helps.

[prezmer]

Do you use localizations for your project?

Yes I do, I used automatic translation. I applied it once, probably before changing TARGETDIR. I've checked translation files using InstallAware Translator. "Set Variable Commands" contains entry:

String Translation (Polish) String Meaning (English)
$PROGRAMFILES$\$TITLE$ $PROGRAMFILES$\$TITLE$

I must say that the behaviour of translation is not obvious. I don't find sense in translation of destination folder. Maybe translation of "set variable" step is useful. It would be good to have some kind of warning (when changing string properties) to avoid problems like mine.

Still, I don't understand why first call to set variable didn't work and second call did. Is there any hidden link between a step and translation files? If yes, it could be good to add something like icon to emphasize that it will be translated.

[ALive]

Agree with you (about strange way the translation implemented), that's why I used LOCMODE=VARSONLY (see help for ScriptReference -> Pre-Defined Compiler Variables for more info). In this case only special Localized variables get translated. Set Variable command does not affected. Pretty useful mode.

When building the project (with translation) ll set variables command (which are translated) will be converted to the translated values. if the value is another variable it will contain the value of that variable (that's was in your case). When Set variable was used another time, but NO translation does. The newly variable will contain just the value it has (no translation at all), because Translator tool (and translated files) does not know how to translate the newly bunch of code (in your case Set variable command).

P.S. So, Michael (I guess you'll read this post ) as I can see there's no bug, but another misuse for the translator engine. Maybe it'll be good to have LOCMODE=VARSONLY turned ON by default. Just a suggestion.

Hope this helps!

[MichaelNesmith]

That is a good suggestion. Actually, even NEWONLY for LOCMODE will prevent problems like this. I paste verbatim from the help file:

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.

So this is the perfect solution as it is a "best of both worlds" approach. The point is obviously giving the developers the convenience of localizing even their setup actions, without having to ship off setup source codes!

[MichaelNesmith]

The latest update to InstallAware 9 R2 (9.08):
www.installaware.com/forum/viewtopic.php?f=2&t=5658

Makes NEWONLY the default value. FYI.