Fun quickfix

[Mike Hearn]

Hi,

Here's an easy to fix bug for somebody wanting to get into Wine hacking,
or who has a spare few minutes.

The basic problem is with the tab control and can be seen by running

http://bylands.dur.ac.uk/~mh/Tab.exe

... that (from control spy).

As you can see on the bottom row, the top of the tabs are overdrawn by the
row above. Putting a Sleep call into the tab drawing code reveals that
we're not drawing the tabs in any particular order (presumably it's the
order they were added) and reading the code indicates that having
TAB_DrawItem overdraw its bottom is the expected behaviour.

The code can be seen in dlls/comctl32/tab.c, in TAB_Refresh and
TAB_DrawItem

One fix is to draw the tabs from top row to the bottom,
instead of in a random order. In order to do that, you need to read the
code in TAB_SetItemBounds and add a new field to TAB_ITEM to record which
row it was placed in. Then, in TAB_Refresh, firstly sort the TAB_ITEMS
topmost to bottommost before drawing them.

This shouldn't be too hard, but would fix a nasty visual glitch in Wine.
If anybody feels like doing it but gets stuck feel free to ask here for
help. On the other hand if you're an old hand at Wine feel free to fix it
too, there's little point keeping bugs around for training purposes :)

thanks -mike

[Uwe Bonnes]

> > > > > "Mike" == Mike Hearn  writes:

Mike> Hi, Here's an easy to fix bug for somebody wanting to get into
    Mike> Wine hacking, or who has a spare few minutes.

Mike> The basic problem is with the tab control and can be seen by
    Mike> running

Mike> http://bylands.dur.ac.uk/~mh/Tab.exe

Commom Controls and "quickfix". This  contradicts ...

[Vitaliy Margolen]

I had been working on this one. Unfortunately I haven't had time lately to work
on it.

Here is what I found:
- All rows is 2 pixels smaller than bottom most one.
- Native draws raws bottom-top. We draw them 1st-last.
- Native draws text first then tabs themselfs. This affects AwnerDraw since tab
  size passed over to owner is bigger then the size for the text.
- When multiline we should invalidate the whole tab area. Right now some portion
  of it is being invalidated. This is best seen with "Ragged Edge" style. When
  tab sizes are not adjusted to fill the whole row.
- Not sure where this one is, but our tab control has 2 pixels thicker border
  then native. This brakes component alignment within each page.

I could try to fix overlapping issue and leave the rest for now. When I tried to
fix all of these problems I got stuck with magic numbers and too many places
that kept braking.

If you'll wait 'til weekend I'll try to submit a patch to fix overlapping issue.

Tuesday, February 24, 2004, 5:43:25 AM, you wrote:
> Hi,
> Here's an easy to fix bug for somebody wanting to get into Wine hacking,
> or who has a spare few minutes.
> The basic problem is with the tab control and can be seen by running
> http://bylands.dur.ac.uk/~mh/Tab.exe
> ... that (from control spy).
> As you can see on the bottom row, the top of the tabs are overdrawn by the
> row above. Putting a Sleep call into the tab drawing code reveals that
> we're not drawing the tabs in any particular order (presumably it's the
> order they were added) and reading the code indicates that having
> TAB_DrawItem overdraw its bottom is the expected behaviour.
> The code can be seen in dlls/comctl32/tab.c, in TAB_Refresh and
> TAB_DrawItem
> One fix is to draw the tabs from top row to the bottom,
> instead of in a random order. In order to do that, you need to read the
> code in TAB_SetItemBounds and add a new field to TAB_ITEM to record which
> row it was placed in. Then, in TAB_Refresh, firstly sort the TAB_ITEMS
> topmost to bottommost before drawing them.
> This shouldn't be too hard, but would fix a nasty visual glitch in Wine.
> If anybody feels like doing it but gets stuck feel free to ask here for
> help. On the other hand if you're an old hand at Wine feel free to fix it
> too, there's little point keeping bugs around for training purposes :)
> thanks -mike