Strange doubling of SUCCESS variable

[Tinus]

Hi Michael,

my setup started to show a strange behaviour. Sometimes the final page does'nt show the run check box.
I narrowed this down using Casic's runtime debug plugin. The problem seems to be a multiplication
of the variable SUCCESS if and only if the Install MSI plugin is used.

This happens if the Install MSI is used to install a pre requisite or to uninstall a previous version.
The problem is related to the thread http://www.installaware.com/forum/viewtopic.php?t=997.
The debugger shows a dummy SUCCESS value after (Un)Install MSI and runtime debug shows 2 variables SUCCESS!.

Every write access to SUCCESS creates a further copy. I have attached a screenshot.
The upper shows the situation after apply install. The lower shows the situation after I set SUCCESS to Reboot.

This is an absolute showstopper for my setup project. Please help and FIX this ASAP!

File Attached:

afterapplyinstall.GIF

[MichaelNesmith]

Install MSI won't duplicate SUCCESS. Of course, you do have to make sure SUCCESS is defined properly before calling Install MSI, if Install MSI is writing to SUCCESS. Is SUCCESS defined before Install MSI is called? Is Install MSI writing to SUCCESS?

In the default script, Install MSI writes only to REMOVEOLD and ERROROLD, both of which are defined before the plug-in command is called.

What are you doing in your script? Which variables are you writing to with plug-in commands? Are you defining them before the plug-in commands are called?

Please double-check that all variables used by plug-ins in your script are defined before the plug-in is called (the IDE already reminds you about this with helpful balloon tips in the plug-in command editors).

[Tinus]

Michael,

you're right - Install MSI doesn't duplicate SUCCESS by itself. Maybe I was not clear enough.

The problem is the combination of Install MSI followed by Apply Install later.
Actually the problem happens with Apply Install but only if a Install MSI was first.

Yes, Install MSI doesn't use SUCCESS but anyway it happens. I have not modified this and I have
no undefined variables. Have a look at the attached screen shot. How can it be?

I will try to create a small demo project.

[Tinus]

Michael,

You can easily reproduce this:

1. Create a Win 32 project.
2. Add c:\\windows\\notepad.exe
3. Use the Casic plugins and add a runtime debug after Apply Install.

Build, run and install for the first time. The runtime debug shows one SUCCESS variable.

Build, run and install for the second time. Old version is uninstalled now. The runtime debug shows two SUCCESS variables.

I have attached a small demo project. My windows is on drive D:, so please change the path for notepad.

[MichaelNesmith]

That's very interesting. I'll escalate this and get back to you. Thanks for reporting!

[MichaelNesmith]

The incorrect values for SUCCESS have been identified as a problem in the variable watches window - and not the script execution engine.

If you add a MessageBox to print $SUCCESS$, you will see that it displays $SUCCESS$ when $SUCCESS$ has not been defined yet (whereas, the variable watches window might display an incorrect value).

Your scripts should run correctly and will not be affected by this problem. This issue only affects the variable watches window and will be resolved in the upcoming update.

Also, I can only conclude that the runtime debug plug-in suffers from the same problem.

[MichaelNesmith]

Please note - I have been advised that if you use the variable watches window to edit variable values after it has begun misreporting variable values in this way, there is a chance that your edits can actually corrupt the in-memory values of variables, as well as the variable names themselves.

[Tinus]

Michael,

Please note - I have been advised that if you use the variable watches window to edit variable values after it has begun misreporting variable values in this way, there is a chance that your edits can actually corrupt the in-memory values of variables, as well as the variable names themselves.

I have not used the variable watches window to edit variable values.

In my setup I have to reboot under certain conditions and do this by setting SUCCESS and REBOOTCOMPUTER.
I noticed that my setup behaves different if a previous version was uninstalled.
Sometimes it does not display the reboot checkbox. So I started to look at SUCCESS.

Your scripts should run correctly and will not be affected by this problem. This issue only affects the variable watches window and will be resolved in the upcoming update.

And I still wonder why the runtime debugger shows a double SUCCESS after Uninstall MSI.
There's no variable watches windows if I run my setup without IDE.

I still think we have two issue here. The one with the watches windows and the other (without debugger at runtime) with SUCCESS and Uninstall MSI.

[MichaelNesmith]

Martin,

The only thing that lead you to believe that there were two SUCCESS variables is the erroneous output produced by either the variable watches window, or the runtime debug plug-in.

If you are still certain there are two SUCCESS variables, or that the value of the SUCCESS variable is getting corrupt, please demonstrate this using MessageBox commands on the $SUCCESS$ variable, with a minimum project that reproduces it. If you can upload such a project here that consistently reproduces this issue, I'll again escalate it and have it resolved.

This was simply the response from the product team to the issue that you raised about this SUCCESS variable, after I escalated it to them.

[Tinus]

Michael,

I apologize. Without runtime debug plug-in I can no longer reproduce the problem.

[casic]

I tried to reproduce the reported behaviour but I never got any variable doubled. Using IA 6.00 and mdPLUGINS 1.0.9. If you have a setup script to reproduce the behaviour, please send me a message so I can check my plugin with this script

Thank you,

Markus

[Tinus]

It's simple (and still happens with 1.0.9).

I've attached my win32 project. Simply install, rebuild and install again. Now the previous version
is uninstalled and that triggers the problem. Look for SUCCESS.
There's a comment *** Problem with SUCCESS ***.

File Attached:

My Win32 Setup.zip

[MichaelNesmith]

Not a problem, Martin - you did help identify the issue with the variable watches window, thank you for that.

[casic]

Hi,

I could reproduce the behaviour and therefor I developed a new plugin to dump out the contents of the variables string (which the plugin receives from InstallAware). I attached the dump to this post. As you can see, there are 3 variables with the name SUCCESS. This works as long as the Runtime Debug plug-in is not used because the plug-in splits all variables into an internal field and sorts this field by the name of the variables. After closing the dialog, all variables are joined to an string and passed back to InstallAware. Depending on the sort function, it can happen, that one of the last variables (which are all empty) is now the first variable in the string. InstallAware uses only the first variable which matches the name -> so a different result may occur. Finally, this behaviour is no bug of the Runtime Debug plug-in because it uses only the data received from InstallAware.

Hope, this issue can be fixed,

Thank you

Markus

File Attached:

Dump.txt

[MichaelNesmith]

Hi All,

Once again, thanks for your diligence with this issue!
I do have good news - engineering was able to nail the problem down. Will be corrected in the latest update.