This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Re: Accessing a string from an installscript function in a commit custom action
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 24, 2009
05:23 AM
Accessing a string from an installscript function in a commit custom action
Hi,
I am working on a Basic MSI project with IS 2010.
This project was originally built with IS 2008.
My project uses a custom action set to commit execution.
This custom action calls an Installscript function that performs a few checks, and displays an error dialog under certain conditions.
This dialog is displayed using the SprintfBox function, with some strings from the ISString table as parameters, ie
This function correctly displayed the error message when we built the setup with IS 2008.
Now we are building the setup with IS 2010, the error message is no longer displayed properly, but the name of the strings are shown instead.
If I schedule the custom action for immediate execution, the message is correctly displayed.
My questions:
Regards
I am working on a Basic MSI project with IS 2010.
This project was originally built with IS 2008.
My project uses a custom action set to commit execution.
This custom action calls an Installscript function that performs a few checks, and displays an error dialog under certain conditions.
This dialog is displayed using the SprintfBox function, with some strings from the ISString table as parameters, ie
SprintfBox( INFORMATION, @ID_String_Title01, @ID_String_Message01 );
This function correctly displayed the error message when we built the setup with IS 2008.
Now we are building the setup with IS 2010, the error message is no longer displayed properly, but the name of the strings are shown instead.
If I schedule the custom action for immediate execution, the message is correctly displayed.
My questions:
- Can an Installscript function no longer access strings of the ISString table in a custom action scheduled for either commit or deferred execution?
- Is it expected, or is it a bug of IS 2010?
- Is it documented anywhere?
- Is there any workaround?
Regards
(3) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 24, 2009
07:01 AM
Hi,
I can confirm that this was due to a bug in ISSetup.dll
The issue no longer occurs if I use ISSetup.dll version 16.0.0.329 available in Q205590.
http://kb.acresso.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=Q205590&sliceId=
Apparently, this new version of ISSetup.dll does not only fix the issue described in Q205590, but also fixes other non-documented problems.
Question to the Acresso developers:
Maybe the Acresso team should update the issue description of Q205590 to describe all the problems that this new version solves?
Or even better, deploy all the fixes through the InstallShield 2010 Software Manager? That would be a good move, wouldn't it?
Regards
I can confirm that this was due to a bug in ISSetup.dll
The issue no longer occurs if I use ISSetup.dll version 16.0.0.329 available in Q205590.
http://kb.acresso.com/selfservice/microsites/search.do?cmd=displayKC&docType=kc&externalId=Q205590&sliceId=
Apparently, this new version of ISSetup.dll does not only fix the issue described in Q205590, but also fixes other non-documented problems.
Question to the Acresso developers:
- Is there any other non-documented problem fixed in this new version of ISSetup.dll you want to tell us about?
Maybe the Acresso team should update the issue description of Q205590 to describe all the problems that this new version solves?
Or even better, deploy all the fixes through the InstallShield 2010 Software Manager? That would be a good move, wouldn't it?
Regards
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 27, 2009
12:52 PM
The original issue could affect any string table handling in deferred, rollback, or commit InstallScript custom actions. Unfortunately, we do not have a comprehensive list of all the possible issues that could have been caused by the change that was in the RTM release of IS 2010.
The issue described by KB Q205590, while not mentioned, was caused by a change to how the language ID of the running setup is determined in InstallScript custom actions. The ID can always be determined in immediate custom actions because the ProductLanguage property can be read by the InstallScript engine. In non-immediate custom actions this property is not available and therefore the engine makes a best-effort attempt at determining what language should be used. This language ID is used to determine which string table should be used by the script engine. The change in IS 2010 caused a language ID of 0 to be used when the engine could not determine what the product language was (and there is never a StringTable0000.txt string table built).
Regarding hotfixes, these are typically delivered through KBs instead of the Software Manager as they do not necessarily affect everyone using the product. Hotfixes are almost always rolled up into a service pack that is delivered through Software Manager.
The issue described by KB Q205590, while not mentioned, was caused by a change to how the language ID of the running setup is determined in InstallScript custom actions. The ID can always be determined in immediate custom actions because the ProductLanguage property can be read by the InstallScript engine. In non-immediate custom actions this property is not available and therefore the engine makes a best-effort attempt at determining what language should be used. This language ID is used to determine which string table should be used by the script engine. The change in IS 2010 caused a language ID of 0 to be used when the engine could not determine what the product language was (and there is never a StringTable0000.txt string table built).
Regarding hotfixes, these are typically delivered through KBs instead of the Software Manager as they do not necessarily affect everyone using the product. Hotfixes are almost always rolled up into a service pack that is delivered through Software Manager.
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Jul 27, 2009
02:56 PM
I ran across this issue looking for a solution to what seemed a totally different problem. Windows Installer service was crashing towards the end of my installation, and I managed to track it down to an InstallScript custom action sequenced in the Commit sequence.
(I need to acknowledge help from George on Acresso's support group here for helping me get that far - thanks, George!)
The crazy thing was
1) I've been using this particular function without incident for a really long time (upwards of 2 years?) on a wide variety of IS versions, operating systems, and install packages
2) There's not much to it. This is it:
It looked like the function wasn't even getting executed since that message box I have in there wasn't even appearing. So I tried grabbing this new ISSetup.dll, just in case there was something new and different in the way InstallScript functions are handled.
Lo, it fixed it. The only connection I see is in Josh's mention of the String0000.txt. When I was first debugging this, I thought it was something in the action RollbackCleanup, since the error happened close to that time and I saw this in the log:
Extracting support file String0000.txt to C:\Users\{bla bla}
Failed to extract file String0000.txt. Error = 0
So I'm not 100% about how this connects, but I can see why it might be. Guess I just need to keep closer tabs on that RSS feed of KB articles... hope this helps someone else.
(I need to acknowledge help from George on Acresso's support group here for helping me get that far - thanks, George!)
The crazy thing was
1) I've been using this particular function without incident for a really long time (upwards of 2 years?) on a wide variety of IS versions, operating systems, and install packages
2) There's not much to it. This is it:
//---------------------------------------------------------------------
// function: RemovePreviousPackage_COMMIT
// purpose: Deletes backup folder.
//---------------------------------------------------------------------
function RemovePreviousPackage_COMMIT(hMSI)
STRING szBackupPath, sCommonAppDataFolder;
NUMBER nBuff;
begin
MsiGetProperty(hMSI, "CustomActionData", sCommonAppDataFolder, nBuff);
szBackupPath = sCommonAppDataFolder ^ "Downloaded Installations\\InstallTemp";
//if (AskYesNo("Backup Path: " + szBackupPath + " Is this correct?", YES) = 1) then
DeleteDir(szBackupPath, ALLCONTENTS);
//endif;
end;
It looked like the function wasn't even getting executed since that message box I have in there wasn't even appearing. So I tried grabbing this new ISSetup.dll, just in case there was something new and different in the way InstallScript functions are handled.
Lo, it fixed it. The only connection I see is in Josh's mention of the String0000.txt. When I was first debugging this, I thought it was something in the action RollbackCleanup, since the error happened close to that time and I saw this in the log:
Extracting support file String0000.txt to C:\Users\{bla bla}
Failed to extract file String0000.txt. Error = 0
So I'm not 100% about how this connects, but I can see why it might be. Guess I just need to keep closer tabs on that RSS feed of KB articles... hope this helps someone else.