annoying EndDialog "feature"

[Andreas Mohr]

On Mon, Feb 05, 2001 at 09:24:42PM +0100, gerard patel wrote:
> At 10:37 AM 5/2/01 -0600, you wrote:
> 
> >> I can't  see this WM_NULL with Winsight. Maybe it's a bug in 
> >> Winsight :-/, but are you sure it's not some framework that is
> >> sending it ?
> >Hmm, what are you talking about ?
> >
> >And I don't quite understand what you're investigating here... ;-)
> 
> *I* don't understand what it is supposed to fix. Using Winsight
> was a rather brainless attempt to see what is happening under
> Windows.
Well, examining how Windows does it can be done,
but I don't think it's too useful, as I think that the current approach
with that fix should work fine.

> Now I think I see : this can only be useful if EndDialog is called from
> another thread, right ? If yes, you really *should* mention this in the
> remark before the code. No need to be mysterious IMHO.
I don't think the "other thread" is important.
What is important is the fact that if we don't get frequent messages,
the dialog will stay open without that fix.

> Anyway, I tested your patch with a thread I launched before the
> DialogBox call; after 15" of sleep the thread is calling EndDialog.
> To add fun I added a WM_NULL handler in the dialog procedure
> to display a  MessageBox; under Windows the MessageBox does not fire,
> under Wine with your patch, it does (test app available)
> So probably Windows does not do it this way (or the WM_NULL message is 
> filtered). It probably does not matter much, granted.
Windows definitely does NOT do it this way, of course
(well, I'd be surprised if it actually did ;-).
This is just a (crude, if you want) hack to make it work.
And I figured sending WM_NULL shouldn't hurt.
I'm open to suggestions on how to rewrite the whole dialog handling
(e.g. to do it like Windows), but I don't think it matters at all
at the moment.
There are much more important things to do.

Andreas Mohr