Assigning Variables to Themselves

[MichaelNesmith]

When you do that, you're triggering an infinite loop! Never set a variable to itself.

[Tiago]

Infinite loop? Damn...

Well, I fixed the problem by writing to a file and then reading it into a variable. Is there any way to add one string to the end of another without calling its name inside the Set Variable statement?

Thanks in advance.

[MichaelNesmith]

Actually, I take that back...looking in InstallAware code, we find:

Set Variable PRELIST to $PRELIST$$NEWLINE$Previous Version Uninstallation

So I think this limitation might have been already transcended - or might have been introduced in a bug during an interim build. What version of InstallAware are you using?

[ALive]

Hi!

If I understand your discussion correctly we cannot use:
Set Variable LIST to $LIST$$NEWLINE$$NEW_LINE$ ???

such method is used in the PREREQ list:
Set Variable PREREQ to TRUE
Set Variable PRELIST to $PRELIST$$NEWLINE$Microsoft Windows Installer 3.1

correct me if i'm wrong...

[Tiago]

I'm using InstallAware Studio 9.

Yeah, I've seen that line too and thought that would work for me. Anyway, I have noticed the problem happens only in the second time I call the variable inside its own Set statement. The first time I use it, when the variable is still blank, everything runs fine.

Well, that's what happens to me.
Thanks for the responsiveness.

[ALive]

Still... this seems weird to me.

I also use such mechanism. Moreover it is a common practice in many program languages (C++, C#, e.t.c.) to reassign a variable.
Ho long is the list you are trying to show? Maybe it's too long?
I don't think using temp file for writing is a "good practice". Because in certain situation you can encounter a write access problem or something.

Anyway, try to print this $LIST$ variable via MessageBox. Maybe there's some unprintable symbol??
B.t.w. do you use localizations?? I know some issues that can take place if using localization unproperly.

Copy/Paste the code you are using (Using Ctrl+Shift+C).

[Tiago]

Yeah, I know that reassigning a variable is a common practice in regular programming languages, and yeah, this is a quite weird situation I'm having here.

The list is intended to show the names of all the features selected by the user in the componentstree dialog. I don't think is a string length matter, once the same string can be read from a file without any problems. I don't think it's a good practice either, but it's the only way I managed to make it work so far. I have considered the unprintable symbol hypothesis, but that's not the case. The only special symbols I'm using are "-" and " " (hyphens and spaces). And no, I'm not using localization.

The code I used is as follows:

Code: Select all

Get Component Server Side Selection State into Variable SELECTED
if Variable SELECTED Equals TRUE
  Set Variable LIST to SERVER SIDE
end
Get Component Server Side\\Shared Folder Selection State into Variable SELECTED
if Variable SELECTED Equals TRUE
  Set Variable LIST to $LIST$$NEWLINE$   - Shared Folder
end
Get Component Server Side\\Database\\Main Selection State into Variable SELECTED
if Variable SELECTED Equals TRUE
    Set Variable LIST to $LIST$$NEWLINE$   - Main Database
end
Get Component Server Side\\Database\\Integration Selection State into Variable SELECTED
if Variable SELECTED Equals TRUE
    Set Variable LIST to $LIST$$NEWLINE$   - Integration Database
end
Get Component Server Side\\Database\\Gateway Selection State into Variable SELECTED
if Variable SELECTED Equals TRUE
    Set Variable LIST to $LIST$$NEWLINE$   - Gateway Database
end
Get Component Server Side\\Application\\DCM License Selection State into Variable SELECTED
if Variable SELECTED Equals TRUE
    Set Variable LIST to $LIST$$NEWLINE$   - DCM License Application
end
Get Component Server Side\\Application\\Alarm Selection State into Variable SELECTED
if Variable SELECTED Equals TRUE
    Set Variable LIST to $LIST$$NEWLINE$   - Alarm Application
end
Get Component Server Side\\Application\\Gateway Selection State into Variable SELECTED
if Variable SELECTED Equals TRUE
    Set Variable LIST to $LIST$$NEWLINE$   - Gateway Application
end
Get Component Server Side\\Application\\Integration Selection State into Variable SELECTED
if Variable SELECTED Equals TRUE
    Set Variable LIST to $LIST$$NEWLINE$   - Integration Application
end
Get Component Server Side\\Application\\Monitor Selection State into Variable SELECTED
if Variable SELECTED Equals TRUE
    Set Variable LIST to $LIST$$NEWLINE$   - Monitor Application
end
Get Component Server Side\\Application\\View Web Selection State into Variable SELECTED
if Variable SELECTED Equals TRUE
    Set Variable LIST to $LIST$$NEWLINE$   - View Web Application
end
Get Component Client Side Selection State into Variable SELECTED
if Variable SELECTED Equals TRUE
    Set Variable LIST to $LIST$$NEWLINE$ CLIENT SIDE
end
Get Component Client Side\\Application\\File Manager Selection State into Variable SELECTED
if Variable SELECTED Equals TRUE
    Set Variable LIST to $LIST$$NEWLINE$   - File Manager Application
end
Get Component Client Side\\Application\\MWS Selection State into Variable SELECTED
if Variable SELECTED Equals TRUE
    Set Variable LIST to $LIST$$NEWLINE$   - MWS Application
end
Get Component Client Side\\Application\\View Web Selection State into Variable SELECTED
if Variable SELECTED Equals TRUE
    Set Variable LIST to $LIST$$NEWLINE$   - View Web Application
end


[MichaelNesmith]

I think I see where the problem is. $LIST$ might even be undefined when you are assigning it to itself. Try to set $LIST$ to something empty, see if that fixes the problem.

When you do this:

LIST=$LIST$ + Something Else

as long as at *that* point of assignment, $LIST$ is something that excludes $LIST$ itself, you'll be fine Otherwise, you end up in an infinite loop. Because LIST is always something plus $LIST$ and you don't know what $LIST$ is at that stage.

Does that make sense?

[Tiago]

Kinda

In regular languages, the result of concatenating something with a null string would be the production of a null string, not an infinite loop. Well, at least we now know about this MSICode particularity. Anyway, my project schedule is a bit overdue, so I'll try your suggestion later.

Thank you very much for the advice!

[MichaelNesmith]

Yeah, the problem in MSIcode is, when you do an assignment before the variable is defined, its not even null.

For instance, this is OK:

Code: Select all

VAR = $UNDEFINED_VAR$ + $DEFINED_VAR$ + CONST

The result will be:

$UNDEFINED_VAR$ + <VALUE> + CONST

But this is not:

Code: Select all

$UNDEFINED_VAR$ = $UNDEFINED_VAR$ + CONST

Because the $UNDEFINED_VAR$ variable is totally unknown at that point and cannot be even substituted in literal form as in the "OK" sample above - it will blow. This can be solved as easily as setting it to an empty string, of course

[Tiago]

Sure!

Thank you very much for the clear explanation, Michael!

[ALive]

Yeah, thank you Michael!

I think this topic could be marked as a sticky. Or create a separate thread with proper header and with your description applied.

Thanks again!