Chained Installs linked to Parent Progress Bar

[Tim_Mayert]

What do I have to do to make sure the chained installs progress is indicated on the parents progress bar?

I want to run all chained children installs in silent mode, but I would like the main parent's progress bar to correctly be incremented according to the chained children installs that are triggered.

So if anyone is doing this instead of having the children msi's run in basic mode then can you let me know the best way to handle this?

Thanks,

[MichaelU]

In order to do this, you need to implement an external UI. Historically this is launched from a bootstrap, but now can be embedded in the .msi as well. Without an external UI, you cannot receive progress messages from the subsequent packages to show in the first's UI.

[Tim_Mayert]

Okay let me get this straight. I could get it to work if I use an External UI or embed in the msi.

So first of all would not the main Parent Setup.exe be the external UI of the Chained MSI's and therefore what would have to be implemented for this to work so that I can run the chained childern msi's in complete silent mode, but have progress indication?

Also if we look at embedding in the .msi, are you talking about the parent and again only if running the parent install through the setup.exe? Again what needs to be implemented to get this to work?

Thanks,

[MichaelU]

There are two different unrelated terms flying around here, so let me clarify. First is related to the kind of UI: Internal or External. Internal is the set controlled by the Dialog, Control, ControlEvent, etc. tables, and refers directly to /qn /qb /qr or /qf. External is any amount of custom UI which, in general, is allowed to fall back to Internal UI.

Second is where an External UI is stored. Traditionally it could only be launched by a controlling bootstrap executable, but Windows Installer 4.5 introduced an Embedded options that allows a .msi file to contain the External UI which it is then able to launch. An Embedded External UI should be compatible with either the InstallShield bootstrap or with being launched directly from the .msi file.

MSI Multiple Package Transactions has a similar option for non-embedded chainers (launched from a bootstrap) or embedded chainers (launched from running a .msi file). InstallShield's support uses the embedded chainer option at this point.

These interact in the following manner. Durning a multi-package transaction using an embedded chainer, there are status messages sent to the "parent" MSI. However none of the Internal UI dialogs can present these messages to the user. In order to capture and present these messages an External UI must be active, and it must handle these messages. When the External UI is not present, the "parent" MSI does not display anything during the installation of the "child" MSIs; running these "children" in Basic UI addresses the impression that the overall installation has hung.

Unfortunately writing a complete External UI is not trivial. It may be possible to avoid some complexity by writing one that specifically replaces the ProgressDialog with one that presents status from the "child" MSIs.

[Tim_Mayert]

So if we look at the EmbeddedUI to do this then can we just create a dll that is called that replaces the internal ui Progress bar have it display an overall progress, or does this mean that if we use EmbeddedUI that we have to use it for the entire UI that is to be displayed?

Since we have not has any experience with EmbeddedUI and from checking the Community it does not look like a lot of others have tryed it or at least posted questions about it.

So what ever information you can supply would be great.

Thanks,

[Tim_Mayert]

Okay looking at Embedded UI looks like quite a bit of work as we can not just replace the Progress Bar we have to replace all internal UI as well as if you want to use Embedded UI it will also skip all the custom action calls with the InstallUISequence table. Most of this information is shown in the following blog:
http://softwareinstall.blogspot.com/

So could someone answer the following questions.

During the parent install could we simply launch a custom action DLL that will use the MSI progress bar custom actions to fake the install progress of the chained msi children?

So could we just use the MsiCreatRecord, MsiRecordSetString, MsiRecordSetInterger, and MsiProcessMessage actions to update the parents progress bar so that we can run the chained installs in complete silent mode and have the progress bar at least update close to what is being installed so that we can avoid having to re-write all the UI and various custom actions that are triggered during the chained install?

[MichaelU]

I don't believe this approach - processing messages in a custom action - would work. I don't see how you could get information to populate, or how this custom action would continue to run during the "child" installations. You might consider a feature request for Microsoft, as in its current form, embedded chainers have very limited support for progress. Or I can see if we have any feature requests in house for better progress reporting in this situation.

[morrischou]

Hi Tim :

I have an InstallScript Project(it's a empty project) be my parent installation , and it calls few child-setups which are InstallScript MSI projects when launch my installation

I set the constant "LAAW_OPTION_USE_CALLBACK" when launching child-setup as below
LaunchAppAndWait( strChildSetupPath ,strCMDLine , LAAW_OPTION_WAIT | LAAW_OPTION_SHOW_HOURGLASS | LAAW_OPTION_USE_CALLBACK ) ;

It will call OnLaunchAppAndWaitCallback() while child-setup is running in silent mode
and SetStatusWindow updates progress % in OnLaunchAppAndWaitCallback() every second

That's how i fake the progress of child-setup to show on setup status of parent installation

MO 😄

[destilant]

How and in which file (e.g. Setup.Rul or featureevents.rul) do you implement OnLaunchAppAndWaitCallback() ? Do you return LAAW_CALLBACK_RETURN_CONTINUE_TO_WAIT in this function like its described in the manuals?

[morrischou]

I use it in featureevents.rul
and I disable the return, I forget why I did that, but the code is running well

===Program===
function number OnLaunchAppAndWaitCallback()
STRING strDisplayMsg ;
NUMBER nTimeClock , nTotalItemNumber ;
begin

My program deals with strDisplayMsg here

SetStatusWindow ( nTimeClock , strDisplayMsg );

// return LAAW_CALLBACK_RETURN_CONTINUE_WAIT;

end;