Hi Dmitri,

> You reverse engineering attempt is almost correct. If you had read
> MsgWaitForMultipleObjects API description you'd see that WAIT_OBJECT_0 + 1
> means that there is a Windows message in the queue of your GUI application
> that makes use of Install API. If this is the case the Install API allows
> you to receive this message and process it by calling FP_STATUS callback
> function that you are supposed to provide. If you use Delphi or C++Builder
> you simply call Application->ProcessMessages() and return successfully.
> Install API indicates when it calls FP_STATUS for this reason. FP_STATUS
> also allows you to advance a Progress Bar that you may want to provide.
>
> If you do not supply FP_STATUS callback and do not process the message
> then MsgWaitForMultipleObjects will always return WAIT_OBJECT_0 + 1
> because the message that arrived to your GUI application will not be
> processed and will remain in the application queue.
>
> We wanted to make application more responsive to user/system actions while
> Install API waits until Microsoft update program completes.

Yes, I supposed something similar, because this problem was only in my GUI
setup and all worked fine in the console variant. But why don't you process
all setup in the separate thread (maybe with its own message queue) to
prevent such lazy developers as me from breaking their mind? I think I
should be responsible for my code only and I wouldn't like to write some
additional code to make an external library working good. Or maybe it's
possible to use WaitForMultipleObjects instead of MsgWaitForMultipleObjects
in the case you have separate thread and thus the message queue won't be
essential. Don't take my opinion for critics, but maybe you'll look at this
thing another way while will be working on the next version.

Just my $0.02.

Best regards,
Dmitry