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
- One of the "documents" has blank client areas (mentioned previously);
these don't ever get drawn.
- 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 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?
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