Forum

Hello,

I just discovered a small display problem with the Office 2007 Silver Theme. This problem can be reproduced with the MDI_DynamicBars sample.

The gradient background visible in the upper menu/toolbar area of the main window ends after about two third of the main window width. Then it changes to a very light brownish background. This way the gradient background looks as if it were divided into two parts.

This problem does not occur with other themes.

Is this a software issue or a problem of our graphics system? Is anybody else able to reproduce this effect?

This behavior is by design. Actually the Office 2007 Silver theme is the same as Office 2003 under the Luna Silver theme. If you open Office 2003, you will see exactly the same gradient.

Ok, I am aware that Microsoft sometimes uses bitmaps of limited width and height (about 600 pixels) to paint gradient backgrounds in their software. Sometimes this causes nasty display effects, if the gradient area is bigger than the dimensions of the bitmap. We are aware of this.

As far as I understand your response it is a design goal of Prof-UIS to emulate even such Microsoft limitations.

Why do you believe it is a limitation of Microsoft Office? We would not agree with you on this. This gradient is not painted with a bitmap. The GradientFill() method works much faster than stretching a bitmap and we are pretty sure Microsoft uses this method (you can make sure of this by setting a low color depth for your desktop). We do not also see any reason not to draw the gradient up to the right most edge of the frame window: this would not affect the performance much. So this design is probably defined in a Microsoft’s specification and we follow this as well.

Would you send us some screenshots with nasty effects so we can offer you an appropriate solution?

Hello,

many thanks for your response.

>>
This gradient is not painted with a bitmap. The GradientFill() method works much faster than stretching a bitmap
<<
I fully agree with you here!! Microsoft sometimes seems to use stretched bitmaps instead of GradientFill() and I like it very much, that Prof-UIS is using GradientFill() instead of such bitmaps. No disagreement about this point!

>>
We do not also see any reason not to draw the gradient up to the right most edge of the frame window: this would not affect the performance much.
<<
But exactly this is the point! You actually do NOT draw the gradient up to the right most edge of the frame window! If you did as you say everything would be perfect. Actually the gradient stops at pixel 686 (search for ’686’ in CExtPaintManager.cpp, please, and you will see what I mean). This causes nasty affects on several of our computers. I will send you a screenshot, that shows this effect.

Thank you for the screenshot. The problem is that you are using the 16-bit color depth for the display. Please find the following lines in the CExtPaintManagerOffice2003::PaintDockerBkgnd method:

if( ! rcDst2.IsRectNull() )
    dc.FillSolidRect( &rcDst2, clrRight );

and replace it with the following:

if( ! rcDst2.IsRectNull() )
{
    if( ::GetDeviceCaps( dc.m_hDC, BITSPIXEL ) > 16 )
        dc.FillSolidRect( &rcDst2, clrRight );
    else
        stat_PaintGradientRect(
            dc,
            rcDst2,
            clrRight,
            clrRight,
            false,
            64
            );
}

This should fix the problem.

Hello,

ok, but why does Prof-UIS draw the complete background in two steps? What is the magic behind the "686" in the CExtPaintManagerOffice2003::PaintDockerBkgnd method?

Hello,

in the meantime I think I found the originator of this effect.

It is line 21926 of CExtPaintManagerOffice2003::PaintDockerBkgnd() where it reads

    if( rcDst.Width() >= 686 )

This divides the gradient background into two parts.

What is the reason to do this?