Windows Vista Aero BorderStyle Paint problem as non Administrator

Above is an image of an inner form (from the C++ project below) before and after I dragged it a little bit up and left to obscure the title bar, then back to the original position. You can see the title, icon, close/minimize buttons were not painted correctly. The same thing happens in Foxpro and VS 2005.


In my prior post, Fix your forms to paint borders correctly under Vista Aero, I showed how Vista Aero doesn’t allow a window that already exists to change its border unless running as an Administrator.


If you run VS 2005 on Vista with Aero as a non-administrator, you can reproduce the same problem with the Windows Form Designer:


Start VS 2005, choose File->New->Visual Basic->Windows Application

Click on the form in the Form designer to select it, then change the FormBorderStyle property to FixedSingle

Now hover your mouse over the ToolBox to make it appear over the form in the designer. Then move your mouse away to let it disappear (or cause any other VS Window to cover the form).


You’ll see that the Titlebar of the form doesn’t get painted correctly: remnants of the toolbox still exist on the title bar. It works fine running VS as Administrator, Vista without Aero, or Windows XP.


I didn’t install C# on this recently borrowed Vista Aero machine, so I can’t test it, but I suspect it’s the same behavior because it’s the same form designer.




Here’re a few lines of sample C++ code that isolates the problem. (Zip file of VS2005 project with EXE available here)

The program simulates a form designer: it creates a child window with a caption initially, turns off the caption, then turns it back on.


Note that for Windows Styles, WS_CAPTION  = WS_BORDER | WS_DLGFRAME



Start VS 2005: choose File->New Project-> Visual C++ Win32  Win32 Project. Call it VistaPaint

In the Win32 Application Wizard, just choose all the defaults and Finish.


Add these lines after this line #include "VistaPaint.h",



#include "atlbase.h"

#include "atlwin.h"


class CForm2 : public CWindowImpl<CForm2>



      DECLARE_WND_CLASS_EX(L"CForm2", 0, COLOR_MENUHILIGHT) // backcolor







and in the WndProc, add this case in the Switch to handle the WM_CREATE message:


      case WM_CREATE:


                  RECT rect;


                  rect.bottom /=2;


                  CForm2 *pCForm2 = new (CForm2);

                  pCForm2->Create(hWnd, &rect,L"CForm2",



                  SetWindowLong(pCForm2->m_hWnd, GWL_STYLE, GetWindowLong(pCForm2->m_hWnd, GWL_STYLE) & ~( WS_CAPTION | WS_SYSMENU) );     // turn off caption (WS_CAPTION  = WS_BORDER | WS_DLGFRAME )

                  SetWindowLong(pCForm2->m_hWnd, GWL_STYLE, GetWindowLong(pCForm2->m_hWnd, GWL_STYLE) | ( WS_CAPTION | WS_SYSMENU) );      // turn on caption (WS_CAPTION  = WS_BORDER | WS_DLGFRAME )






Last, change the InitInstance code to add the WS_CLIPCHILDREN flag: Change the CreateWindow line in InitInstance from



   hWnd = CreateWindow(szWindowClass, szTitle, WS_OVERLAPPEDWINDOW,




   hWnd = CreateWindow(szWindowClass, szTitle, WS_OVERLAPPEDWINDOW | WS_CLIPCHILDREN ,




Now hit F5 to run the code. Move the inner window inside the outer to cause the border to repaint. Observe the border doesn’t get repainted.


Now run the same app as an Administrator (start Windows Explorer, navigate to the Project Debug directory, right click on the EXE file and choose Run as Administrator). Observe that the border paints correctly.



For even more fun, comment out the DECLARE_WND_CLASS_EX line!




Comments (9)

  1. Tracy Pearson says:

    Thank you for understanding this problem and showing us it can also happen in other languages. It helps to know it isn’t just a VFP issue. Using the following VFP command in the INIT event prevents this problem from appearing.


    Is this due to the form being recreated/reassigned to a parent window?

    In the baseclasses I use, the forms INIT changes the borderstyle to 2 from 3. This allows changing the size of the form at design time, without forgetting to reset the borderstyle before compile. (One less thing to remember and still get the polished look and feel)

  2. Calvin_Hsia says:

    Tracy: in my prior blog post I mentioned that the Aero painting problem only exists if the BorderStyle is changed after the Window is created, such as in Forms (SCX files).  

    Forms that are in VCX (Visual Class Library) files and forms that inherit from VCXs may have the BorderStyle set already by the time the Window is created.

  3. Sietse Wijnker says:


    By a client (including screenshots) I’ve been reported a glitch in a VFP9 (no SP) application running in Vista that might be related:

    When a popup context menu is shown close to the left border of the screen, and one of the selections shows a second popup, the popup is shown left of the 1st popup. Most of the 2nd popup is outside of the visible screen. The behaviour is not reproducable in XP.

    I mentioned this behaviour on the ProFox-mail and someone there suggested I could mention it to you. Maybe you can shed some light on the behaviour?

  4. In this post: Foxpro Menu items, combo boxes not refreshing selected item under Aero in Vista I describe

  5. Cesar Chalom says:

    Here are some of the links that I often visit regarding VFP9 SP2 and Sedna. The official Microsoft Visual…

  6. I’ve been reading the comments here and on some sites about SP2. I wanted to give my point of view about

  7. We’ve figured out the Vista border issue (we think). We couldn’t reproduce it here, but Jim Slater noted

  8. Hello,

    When i cahange the size of the Windows Vista’s window, the caption colour changes. I give you a screenshot of the problem at the link below.

    Can you explain me how i can prevent this change. Thanx.

    Regards and happy new year,


    Screenshot Link:

  9. 出会い says:


Skip to main content