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.
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.
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.
Gerard
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
-
Andreas Mohr -
gerard patel