thread confusion

[Bill Medland]

I just noticed this while looking into a problem with the ComboBox code.  It
makes no sense to me.

The application runs a container executable which then loads up an OCX
(based on the command line).  Part of that OCX includes a control based on
the ComboBox control.  (That's another story).

I added a couple of MessageBox calls in the source of the control's code.
While the OCX was loading the "before" and "after" message boxes were
displayed as expected.  However once the OCX was up and I pulled down the
dropdown list the "before" message box popped up TWICE and you had to say OK
to them in the correct order to get the pair of "after" boxes.  So I
included GetCurrentThreadID in the message they displayed, thinking that we
now had two threads.  But both had (or appeared to have) the same thread ID.
So I turned on the dialog warnings and, yes, the second call to MessageBox
was occurring while the first was still executing.

Anyone know what is going on there?

Bill

[Ove Kaaven]

On Tue, 20 Aug 2002, Bill Medland wrote:
> I added a couple of MessageBox calls in the source of the control's code.
> While the OCX was loading the "before" and "after" message boxes were
> displayed as expected.  However once the OCX was up and I pulled down the
> dropdown list the "before" message box popped up TWICE and you had to say OK
> to them in the correct order to get the pair of "after" boxes.  So I
> included GetCurrentThreadID in the message they displayed, thinking that we
> now had two threads.  But both had (or appeared to have) the same thread ID.
> So I turned on the dialog warnings and, yes, the second call to MessageBox
> was occurring while the first was still executing.
>
> Anyone know what is going on there?

It's not that surprising. Though MessageBox will in your cause block the
processing of the message you called it in, MessageBox runs its own
message loop (complete with DispatchMessage), so *new* messages can still
be received, dispatched, and processed when the messagebox is running,
which means that your handler can easily get recursed into, and under the
right circumstances, you can even get infinite recursion, overload and
crash Windows, and need to reboot...

[Bill Medland]

Thanks to everyone for all the replies.  I guess it was obvious if I had
bothered to think.

I don't intend doing anything about it (since it was debug code and I am
passed there now) but I forgot to mention that this was only under WINE;
under windows it was fine.  I guess we can leave it for when we have some
time.

Bill
----- Original Message -----
From: "Ove Kaaven" 
To: "Bill Medland" 
Cc: "wine-devel" 
Sent: Wednesday, August 21, 2002 12:39 PM
Subject: Re: thread confusion
> On Tue, 20 Aug 2002, Bill Medland wrote:
> > I added a couple of MessageBox calls in the source of the control's

code.
> > While the OCX was loading the "before" and "after" message boxes were
> > displayed as expected.  However once the OCX was up and I pulled down

the
> > dropdown list the "before" message box popped up TWICE and you had to

say OK
> > to them in the correct order to get the pair of "after" boxes.  So I
> > included GetCurrentThreadID in the message they displayed, thinking that

we
> > now had two threads.  But both had (or appeared to have) the same thread

ID.
> > So I turned on the dialog warnings and, yes, the second call to

MessageBox
> > was occurring while the first was still executing.
> >
> > Anyone know what is going on there?
>
> It's not that surprising. Though MessageBox will in your cause block the
> processing of the message you called it in, MessageBox runs its own
> message loop (complete with DispatchMessage), so *new* messages can still
> be received, dispatched, and processed when the messagebox is running,
> which means that your handler can easily get recursed into, and under the
> right circumstances, you can even get infinite recursion, overload and
> crash Windows, and need to reboot...