App works almost perfectly, but one MDI screen won't draw

[Duane Clark]

Mike Hearn wrote:
>>So then it becomes a matter of figuring out where they should 
>>be generated.
> 
> 
> Yeah, that's the big that usually gets me :) Are they the sort of
> messages that should be generated by Wine or the app?

By Wine. In general, I have found message bugs relatively 
straightforward to fix.

> What happens if the app doesn't call BeginPaint in a WM_PAINT handler.
> Is that an API violation, or are there reasons for it? MSDN had an
> explanation that seemed to suggest that in certain unusual circumstances
> you didn't need to call it, but I don't remember exactly what.

Yea, I want to try to figure out the exceptions and add something to 
silence those messages. In this case, they appear to be a "red herring". 
Looking at SPY++, the WM_NCPAINT and WM_ERASEBACKGROUND messages should 
have been sent prior to posting the WM_PAINT message. But more studying 
to come.

>>It is a bit of a 
>>mystery to me why the call is bad; it is a call directly from the app. I 
>>wonder if the wrong function is being called for some reason. But that 
>>is something I will look into later.
> 
> How common is it for apps to actually make bad API calls? QuickTime
> seemed to do that, is it rare or not?

I don't really know. From the looks of this one, I cannot believe the 
app was written this incorrectly, so the bug must be something more 
subtle. I think I am going to have to resort to disassembling the small 
portion of the app that makes the call to figure out what is happening. 
Fortunately, the location shows up just fine in winedbg when it crashes, 
so that makes things easier.