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

[Dan Kegel]

I've played with our MDI application a bit more, and have
observed two kinds of bugs under cvs wine:

First type: things not drawing, probably because of missing messages
(we know the WM_NCPAINT message is AWOL, but it might be something
else);

1. One of the "documents" has blank client areas (mentioned previously);
these don't ever get drawn.

2. Another of the "documents" has a blank pane initially, but
if you diddle around a bit, it does draw.

3. Maximizing any of the "documents" is supposed to make a
minimize/maximize/close widget appear on the right-hand side of
the toolbar, but it doesn't.

Second type: things drawing in the wrong place:

4. The text box at the bottom of a three-panel window has its
upper left corner in the right place, but its lower right corner
is exactly one scrollbar width inset too far.
The scrollbars are inset by that amount, too.  That leaves the area
where the scrollbars ought to be totally undrawn.

Duane Clark is looking at the missing message problem in this
and another app.

Also, I'm setting up Linux and Wine for the guy
who wrote our app so he can poke around and look
for these problems himself; if nothing else, he can
put together a minimal test case.
- Dan

-- 
Dan Kegel
http://www.kegel.com
http://counter.li.org/cgi-bin/runscript/display-person.cgi?user=78045

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

[Mike Hearn]

> 1. One of the "documents" has blank client areas (mentioned previously);
> these don't ever get drawn.
>
> 2. Another of the "documents" has a blank pane initially, but
> if you diddle around a bit, it does draw.

These sound like a problem I'm seeing with the Adobe SVG plugin,
which means that unfortunately I have to go back to Windows during
the day. Basically the app doesn't blit its backbuffer in response
to WM_PAINT messages in my case, however, forcing it to redraw itself, 
for instance due to animation, or a mouseover script causing it to change
makes it happen.

I keep meaning to look into it, last time I tried I was pretty inexperienced
at reading relay traces (well, still am :).

-- 
Mike Hearn <m.hearn(a)signal.qinetiq.com>
QinetiQ - Malvern Technology Center

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

[Duane Clark]

Mike Hearn wrote:
> These sound like a problem I'm seeing with the Adobe SVG plugin,
> which means that unfortunately I have to go back to Windows during
> the day. Basically the app doesn't blit its backbuffer in response
> to WM_PAINT messages in my case, however, forcing it to redraw itself, 
> for instance due to animation, or a mouseover script causing it to change
> makes it happen.
>
> I keep meaning to look into it, last time I tried I was pretty inexperienced
> at reading relay traces (well, still am :).

I spent a lot of time learning how the bitblt stuff works for the patch 
I sent in a few weeks ago (which was to fix a similar problem), and 
stared at a lot of relay traces related to that. So if you narrow it 
down to a small part of the relay trace and are stuck, go ahead and send 
it to me (or post it). The bitblt stuff is rather tricky.

I'm assuming "Adobe SVG" is a commercial product?

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

[Hetz Ben Hamo]

> I'm assuming "Adobe SVG" is a commercial product?

It's a free (as a beer) plugin for the browsers to show SVG graphics 
(competitor to flash).

Hetz