Assigning Variables to Themselves
-
- Posts: 3452
- Joined: Thu Dec 22, 2005 7:17 pm
- Contact:
Assigning Variables to Themselves
When you do that, you're triggering an infinite loop! Never set a variable to itself.
Michael Nesmith
InstallAware
Home of The Next Generation MSI Installer
Get your free copy today - http://www.installaware.com/
InstallAware
Home of The Next Generation MSI Installer
Get your free copy today - http://www.installaware.com/
-
- Posts: 3452
- Joined: Thu Dec 22, 2005 7:17 pm
- Contact:
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?
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?
Michael Nesmith
InstallAware
Home of The Next Generation MSI Installer
Get your free copy today - http://www.installaware.com/
InstallAware
Home of The Next Generation MSI Installer
Get your free copy today - http://www.installaware.com/
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.
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.
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).
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).
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:
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
-
- Posts: 3452
- Joined: Thu Dec 22, 2005 7:17 pm
- Contact:
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?
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?
Michael Nesmith
InstallAware
Home of The Next Generation MSI Installer
Get your free copy today - http://www.installaware.com/
InstallAware
Home of The Next Generation MSI Installer
Get your free copy today - http://www.installaware.com/
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!
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!
-
- Posts: 3452
- Joined: Thu Dec 22, 2005 7:17 pm
- Contact:
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:
The result will be:
But this is not:
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
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
Michael Nesmith
InstallAware
Home of The Next Generation MSI Installer
Get your free copy today - http://www.installaware.com/
InstallAware
Home of The Next Generation MSI Installer
Get your free copy today - http://www.installaware.com/
Who is online
Users browsing this forum: No registered users and 17 guests