0
votes

I have a custom action, say CA1, that works with PIDKEY entered from a dialog, say Dlg1. According to the value of the PIDKEY, CA1 writes some value to a property and some components have that property as part of thier conditions. Because CA1 needs PIDKEY and component conditions are evaluated at CostFinalize, CA1 must be placed after Dlg1 and before CostFilnalize.(Dlg1 -> CA1 -> CostFinalize)

But it appears that unless I manually author the sequence number of those actions, CostFinalize(1000 in both InstallUISequence and InstallExecuteSequence) action always comes before Dlg1(1297 in InstallUISequence). So, I just scheduled CA1(in InstallExecuteSequnce) before both CostFinalize and Dlg1.(CA1 -> CostFinalize -> Dlg1) Interestingly, although I expected wrong result, it works exactly as I expected.

I checked log file and it showed the order (Dlg1 -> CA1 -> CostFinalize) which is not consistent with MSI table at all. I don't understand what's going on and want to know how to determine what action comes first by vieweing MSI table(InstallUISequence and InstallExecuteSequence).

2

2 Answers

1
votes

All actions from InstallExecuteSequence are executed after you press the button "Install", thus after you pass through Dlg1.

The execution of the custom and standard actions from an MSI is explained in the linked article with more details and a little bit of graphics.

0
votes

You should allow for the possibility that the PIDKEY is mistyped or otherwise invalid. Therefore I would call a custom action from the Next Button of the dialog using a DoAction ControlEvent. Perform a SpawnDialog to display an error if it's invalid and allow transition to the next dialog if it is valid.

The custom action should also be scheduled in the InstallExecuteSequence to allow for support of silent installs. Use a Type 19 Error custom action to abort the installation if the PIDKEY proves to be invalid.