Dmitri Smirnov wrote:

>
>
> Dmitry,
>
> > BTW, I should note that there's a problem I've found while was working with
> > Install API. I don't know what exactly is wrong, because I haven't seen the
> > source code, so I can only suppose. The problem is within
> > 'isc_install_execute' implementation.
>
> 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.

I was not completely correct (Linux does take its toll).
MsgWaitForMultipleObjects does not return if there is a previous input.
However, MsgWaitForMultipleObjects is called with QS_ALLINPUT option and
the amount of messages it will react to is simply astonishing. Even if you
just move a mouse there will be a few messages. So you better provide the
callback.

--
Dmitri Smirnov
Borland
x6558