Guide to WIN32 Paint for Intermediates

• Download source files - 14 Kb
• Download demo project - 70 Kb

Introduction

Many developers are comfortable with obtaining a handle to a device context (DC) and painting to it. However there is probably alot of confusion in how all of the parts to windows painting are structured. Confusion in what the different DCs are good for, and how each of these DCs can be used effectively. This article will describe in detail, how the different parts of the WIN32 paint system are combined and how to use the common and device DCs in the paint system. The memory and metafile DCs will be ignored in this article.

This tutorial will also explain how the SDK relates to each of the wrapper classes for MFC and WTL. With this knowledge, developers can then make wiser decisions on when you will create, cache, and use DCs in your Windows painting. The tutorials and code examples are written in WTL, however, the wrapper classes are very similar for both MFC and WTL.

There is a beginner tutorial that precedes this article. The preceding artical covers basics of painting to a window with a DC. This article is entitled: Guide to WIN32 Paint for Beginners.

Anatomy of a Window

A window is the fundamental object through which information is conveyed to a user in WIN32 operating systems. A window is a system resource that is managed by the operating system and can be accessed by the host application with a window handle (HWND). There are many pieces of information that describe a window. This section will describe the different characteristics that relate to paint.

Physical Characteristics

The portion of a window where most of the information is displayed is called the client area. Most often this area is represented by a rectangle. The rectangle can be retrieved from the window with this function:

::GetClientRect(HWND hWnd, RECT *pRect);

Often times, the client area will be surrounded by a region of the window called the non-client area. The non-client area encompasses the window borders, caption and the menus if any are present. A rectangle that represents the non-client area can be retrieved from the window with this function:

::GetWindowRect(HWND hWnd, RECT *pRect);

This function differs from GetClientRect in the fact that the rectangle is returned in screen coordinates, and the rectangle also encompasses the client area of the window. Therefore, if an application simply wants to access the region that represents the client area of the window, then this code must be performed:

RECT rWindow;
RECT rClient;

HRGN hRgnWindow;
HRGN hRgnClient;
HRGN hNCRgn;

//C: Get the window and client rectangles for the window.

::GetWindowRect(hWnd, &rWindow);
::GetClientRect(hWnd, &rClient);

//C: Translate the Client rectangle into screen coordinates.

POINT pt = {0,0};
::MapWindowPoints(hWnd, NULL, &pt, 1);
::OffsetRect(&rClient, pt.x, pt.y);

//C: Create regions from these two rectangles.

hRgnWindow = ::CreateRectRgnIndirect(&rWindow);
hRgnClient = ::CreateRectRgnIndirect(&rClient);
hNCRgn	   = ::CreateRectRgn(0,0,0,0);	

//C: Subtract the client region from the window region.

::CombineRgn(hNCRgn, hWindowRgn, hClientRgn, RGN_DIFF);

//C: Perform actions on the NC region.

...

//C: Free region resources.

::DeleteObject(hRgnWindow);
::DeleteObject(hRgnClient);
::DeleteObject(hNCRgn);

Here is a picture that illustrates the different regions of a window:

Update Region

The WIN32 kernel manages the state of a window. One of the most important elements of a window is its update region. The update region remembers all of the portions of the window that need to be redrawn. A region may need to be redrawn for a number of reasons:

• Another window occludes the view of the target window.
• The window is resized, restored from a minimized state, or maximized.
• The window is activated or deactivated and the caption needs to be repainted.
• The application forces the window to repaint itself.

At any point in time the application can query the current update region for a window with this code:

//C: This code will get the entire update region.

HRGN hUpdateRgn;
hUpdateRgn = ::CreateRectRgn(0,0,0,0);

::GetUpdateRgn(hWnd, hUpdateRgn, FALSE);

//C: This code will simply retrieve the bounding box of the update region.

RECT rUpdateBox;
::GetUpdateRect(hWnd, &rUpdateBox, FALSE);

The update region can be very important for applications that would like to clip their painting code to the update region in order to improve performance.

The application can modify the update region manually, either by adding a new portion to the update region, in effect invalidating the region, or by subtracting away from the update region, or validating that region. Here is the set of functions that can be used to modify the update region.

InvalidateRect

The InvalidateRect function adds a rectangle to the specified window's update region.

BOOL InvalidateRect(
  HWND hWnd,           // handle to window

  CONST RECT *lpRect,  // rectangle coordinates

  BOOL bErase          // erase state

);

InvalidateRgn

The InvalidateRgn function invalidates the client area within the specified region by adding it to the current update region of a window.

BOOL InvalidateRgn(
  HWND hWnd,    // handle to window

  HRGN hRgn,    // handle to region

  BOOL bErase   // erase state

);

ValidateRect

The ValidateRect function validates the client area within a rectangle by removing the rectangle from the update region of the specified window.

BOOL ValidateRect(
  HWND hWnd,          // handle to window

  CONST RECT *lpRect  // validation rectangle coordinates

);

ValidateRgn

The ValidateRgn function validates the client area within a region by removing the region from the current update region of the specified window.

BOOL ValidateRgn(
  HWND hWnd,  // handle to window

  HRGN hRgn   // handle to region

);

RedrawWindow

The RedrawWindow function updates the specified rectangle or region in a window's client area. This function will modify the update region. This function can also force a repaint of the window and its children based on the flags that are set.

BOOL RedrawWindow(
  HWND hWnd,               // handle to window

  CONST RECT *lprcUpdate,  // update rectangle

  HRGN hrgnUpdate,         // handle to update region

  UINT flags               // array of redraw flags

);

Here is a list of the flags that can be used with this function and a short description of what each flag does:

• RDW_ERASE: Causes the window to receive a WM_ERASEBKGND message when the window is repainted.
• RDW_FRAME: Causes a WM_NCPAINT message to be sent.
• RDW_INTERNALPAINT: Causes a WM_PAINT message to be posted to the message queue even if the update region is empty.
• RDW_INVALIDATE: Invalidates the window with either lprcUpdate or hrgnUpdate. If both of these are NULL, then the entire window is invalidated.
• RDW_NOERASE: Suppresses any pending WM_ERASEBKGND message.
• RDW_NOFRAME: Suppresses any pending WM_NCPAINT messages.
• RDW_NOINTERNALPAINT: Suppresses any internal WM_PAINT messages that are not a result of the update region.
• RDW_VALIDATE: Validates the window with either lprcUpdate or hrgnUpdate. If both of these are NULL, then the entire window is validated.
• RDW_ERASENOW: WM_ERASEBKGND and WM_NCPAINT messages will be sent before the function exits.
• RDW_UPDATENOW: The window will be sent a WM_PAINT message before the function exits.
• RDW_ALLCHILDREN: Includes any children in the repainting operations.
• RDW_NOCHILDREN: Excludes any children from the repainting operations.

Class Styles that Affect the Update Region

There are two class styles for a window that will affect the update region for a window when the window is sized. These are CS_HREDRAW and CS_VREDRAW. These flags can be set in any combination. If the window is resized in a horizontal fashion and the CS_HREDRAW style is set, the entire display will be invalidated and redrawn. Likewise, if the window is resized vertically and the CS_VREDRAW style is set the entire display will be invalidated. These styles can be useful for displays where the view can be scrolled.

The WM_PAINT / WM_NCPAINT Messages

A window is responsible to paint its own display. A window should paint its display in response to a WM_PAINT message. If the non-client region should be updated then the painting should occur in WM_NCPAINT. WM_PAINT and WM_NCPAINT messages are only generated when the update region is not empty. There are other ways to force a WM_PAINT message to be generated, as stated above, the RedrawWindow function can do this. It is not wise, however, to send a WM_PAINT message directly because of the nature of the update region.

When the WM_PAINT and WM_NCPAINT messages are handled, they must be handled properly. The largest risk is the mismanagement of the update region. If portions of this region are prematurely validated, then parts of the window will never be updated. On the otherhand, if portions of the update region are never validated, then the system will believe that the window always needs to be updated, and will continue to send WM_PAINT messages. THis will have a serious effect on performance.

The WM_ERASEBKGND Message

The WM_ERASEBKGND message is generated to clear a window's client area before that window is painted. The WM_ERASEBKGND message is generated in a few places. The most common place this message is generated is in the WM_PAINT handlers call to BeginPaint. That is another reason why it is important to call BeginPaint inside of the WM_PAINT handler.

The WM_ERASEBKGND message is passed a pre-initialized DC in the wParam parameter. An application that handles WM_ERASEBKGND should use this DC to paint the bacground, because any drawing actions that are performed will be clipped to the current update region in order to reduce flicker on the update.

Device Contexts

There are four types of DCs. The fundamental purpose of each DC is to provide a basis for drawing on a device. The area that can be drawn is determined by the type of DC that is created. This section will describe the different types of DCs that are used in painting and how they are encapsulated by MFC and WTL.

The first type of DC that will be described is the common DC. The common DC encapsulates two types of DCs, the window DC and the client DC. Then a second section will follow with Device DCs. These are DCs that represent any device on your machine, that supports some form of the Windows Graphics Device Interface (GDI). Two other types of DCs are ignored in this article, memory DCs, and metafile DCs.

A DC is an operating system resource. Because of this, it is very important that DCs are released when they are no longer required. Do not cache DCs. Each type of DC has its own method to release that DC. It is important to use the proper function because these functions act like desctructors, and important shutdown operations occur in these functions for the particular type of DC. If an application performs a lengthy operation each time to initialize a DC, then a class or private DC can be created. That will be explained at the end of this section.

Common DCs

Common DCs are created from a pool of DCs that is limited by the amount of memory on the current system. Common DCs are futher classified as Client and Window DCs. Client and Window DCs are avery similar. The only difference between the two is that a client DC is restricted to the client area of the window, while the window DC gives the application access to both the client and the non-client areas of the window. There are two functions that allow access to a client DC (BeginPaint and GetDC,), one function to create a window DC (GetWindowDC) and one master function that will allow any sort of DC to be created for a window (GetDCEx).

Listed below is each of the functions that can be used to created a DC for a window. Any special characteristics about each function are described, as well as special uses.

Paint DC

A paint DC is represented in MFC and WTL by the CPaintDC class. This class is a wrapper around the BeginPaint function, which prepares the specified window for painting and initialize the PAINTSTRUCT structure with information about the painting.

HDC BeginPaint(
  HWND hwnd,            // handle to window

  LPPAINTSTRUCT lpPaint // paint information

);

BeginPaint prepares the window for painting by creating a client DC with a clipping region that is equivalent to the update region for the window. Then the update region is validated to prevent the generation of other WM_PAINT messages. The clipping region is set into the client DC on repaint because when the entire display is repainted, this has the effect of reducing a great portion of the flicker. However, this form of clipping will not remove all forms of flicker, especially for complicated displays that take a long period of time to repaint.

Here is the layout of the PAINTSTRUCT structure:

struct PAINTSTRUCT { 
  HDC  hdc; 
  BOOL fErase; 
  RECT rcPaint; 
  BOOL fRestore; 
  BOOL fIncUpdate; 
  BYTE rgbReserved[32]; 
};

Here is a description of each of the fields:

• hdc: The handle to the DC that is created in BeginPaint. This is the same handle that is returned from BeginPaint.
• fErase: Indicates whether the application is responsible for erasing the background of the paint display. If the call to WM_ERASEBKGND succeeds, then this parameter will usually be FALSE.
• rcPaint: Specifies a RECT structure that specifies the upper left and lower right corners of the rectangle in which the painting is requested. This is basically the bounding rectangle of the update region for the window.
• fRestore: Reserved; used internally by the system.
• fIncUpdate: Reserved; used internally by the system.
• rgbReserved: Reserved; used internally by the system.

BeginPaint performs a few other actions while preparing the window to be painted. It will hide the caret if the current window contains a caret in order to prevent the window from painting over it. It will send a message to WM_NCPAINT in order to update the borders if necessary. After the DC has been initialized with the current clipping region, then a message to WM_ERASEBKGND will be sent. WM_ERASEBKGND will only erase the current update region.

The CPaintDC class properly disposes of the DC with a call to EndPaint. The EndPaint function marks the end of painting in the specified window. This function is required for each call to the BeginPaint function, but only after painting is complete. One extra thing that EndPaint does is restores the caret to the screen that was previously hidden in the call to BeginPaint.

BOOL EndPaint(
  HWND hWnd,                  // handle to window

  CONST PAINTSTRUCT *lpPaint  // paint data

);

The only place that BeginPaint should be called is inside of the WM_PAINT handler. This is because of the update region. If a DC is required outside of the WM_PAINT handler, GetDC should be used instead.

Client DC

A DC that paints the client area, but is not a Paint DC is referred to a ClientDC in MFC and WTL. This DC is represented by the CClientDC class. This class encapsulates a call to GetDC. This type of DC should be used any place that requires painting to the client region of a window except in the OnPaint handler. GetDC can also get a DC to paint on the entire screen if NULL is passed in as the window handle.

HDC GetDC(
  HWND hWnd   // handle to window

);

After painting with a common DC, the ReleaseDC function must be called to release the DC. Class and private DCs do not have to be released. ReleaseDC must be called from the same thread that called GetDC. The ReleaseDC function releases a device context (DC), freeing it for use by other applications. The effect of the ReleaseDC function depends on the type of DC. It frees only common and window DCs. It has no effect on class or private DCs.

int ReleaseDC(
  HWND hWnd,  // handle to window that the DC was created for.

  HDC hDC     // handle to DC

);

Window DC

A Window DC allows for the entire window, including title bar, menus, and scroll bars, to be painted. A window device context permits painting anywhere in a window, because the origin of the device context is the upper-left corner of the window instead of the client area. MFC and WTL represent this DC with the CWindowDC class, which intenally calls the GetWindowDC function to create the DC. GetWindowDC can also get a DC to paint on the entire screen if NULL is passed in as the window handle.

HDC GetWindowDC(
  HWND hWnd   // handle to window

);

As with GetDC, GetWindowDC should be released with a call to ReleaseDC, which CWindowDC takes care of automatically.

GetDCEx

GetDCEx is the function that will allow the developer to create a DC that is associated with any part of a window. The three functions that were previously listed are all implemented with a call to GetDCEx. GetDCEx can also get a DC to paint on the entire screen if NULL is passed in as the window handle.

HDC GetDCEx(
  HWND hWnd,      // handle to window

  HRGN hrgnClip,  // handle to clipping region

  DWORD flags     // creation options

);

The flags parameter will determine which type of DC will be created, and how the DC will be initialized. Here is a short list of the different flags that can be used to create a DC with GetDCEx:

• DCX_WINDOW: Returns a DC that corresponds to the window rectangle rather than the client rectangle.
• DCX_CACHE: Returns a DC from the cache, rather than the OWNDC or CLASSDC window. Essentially overrides CS_OWNDC and CS_CLASSDC.
• DCX_PARENTCLIP: Uses the visible region of the parent window. The parent's WS_CLIPCHILDREN and CS_PARENTDC style bits are ignored. The origin is set to the upper-left corner of the window identified by hWnd.
• DCX_CLIPSIBLINGS: Excludes the visible regions of all sibling windows above the window identified by hWnd.
• DCX_CLIPCHILDREN: Excludes the visible regions of all child windows below the window identified by hWnd.
• DCX_NORESETATTRS: Does not reset the attributes of this DC to the default attributes when this DC is released.
• DCX_LOCKWINDOWUPDATE: Allows drawing even if there is a LockWindowUpdate call in effect that would otherwise exclude this window. Used for drawing during tracking.
• DCX_EXCLUDERGN: The clipping region identified by hrgnClip is excluded from the visible region of the returned DC.
• DCX_EXCLUDEUPDATE: Behaves the same as DCX_EXCLUDERGN, except the update region of the window is used as input rather than the hrgnClip parameter.
• DCX_INTERSECTRGN: The clipping region identified by hrgnClip is intersected with the visible region of the returned DC.
• DCX_INTERSECTUPDATE: Behaves the same as DCX_INTERSECTRGN, except the update region of the window is used as input rather than the hrgnClip parameter.
• DCX_VALIDATE: When specified with DCX_INTERSECTUPDATE, causes the DC to be completely validated. Using this function with both DCX_INTERSECTUPDATE and DCX_VALIDATE is identical to using the BeginPaint function.

As stated earlier, BeginPaint, GetDC, and GetWindowDC are all implemented in terms of GetDCEx. Listed below is a table of these flags, and the proper call that should be made to GetDCEx in order to create an equivalent DC. In all of the examples, hWnd is the handle to the target window.

• BeginPaint:

  ::GetDCEx(hWnd, NULL, DCX_INTERSECTUPDATE | 
                        DCX_VALIDATE | /* Other flags depending on class styles*/);
  

• GetDC:

  ::GetDCEx(hWnd, NULL, NULL);
  

• GetWindowDC:

  ::GetDCEx(hWnd, NULL, DCX_WIDNOW);
  

Class / Private DCs

It is important not to cache the common DCs in an application. How then can an application create a DC that does not have to be reinitialized each time it is called? This can be done with either a class or private DC. These two DCs can be retrieved in the same manner as the other common DCs and they do not need to be released. However it is good practice to release these DCs as the release functions have no effect, and memory leaks will be prevented if the DCs are ever converted back to common DCs.

Class and private DCs are persistant, therefore the state of the DC will remain the same as it was in the previous call to that DC. This will allow a DC to be initialized once. This could save valuable time for applications that have lengthy DC initializations.

Given below is a short description of both the class and private DC.

Class DC

A class DC is created for use for a single window class. In order to create a class DC, the window class must have the CS_CLASSDC style set. Since it is possible to create two windows of the same class on different threads, it is important to synchronize access to a class DC. Simultaneous use of a class DC on two different threads has undefined behaviour.

Private DC

A private DC is created for one particular window. To create a private DC, the CS_OWNDC style must be set in the class of the window.

Device DCs

A device DC allows access to any device on the system that supports some portion of the WIN32 GDI. All types of devices can be accessed like the "DISPLAY" driver, secondary monitors, printers, plotters and any other cutting-edge device that supports GDI.

There are two steps that are required to get a handle to a device DC. 1) Get the name of the device. 2) Call CreateDC to create the HDC for the device. When the application is finished with the DC, DeleteDC should be used to destroy the HDC.

Obtain Device Name

Most simply, if the application would like a DC to the primary display device, then the string "DISPLAY" can be used. However if a DC is to be created for secondary monitor then EnumDisplayMonitors must be used in order to get the name of the target display driver, since multi-monitor support does not exist on WIN95, this function is only valid on WIN98 and above.

In order to get the name of a printer device, the application should use EnumPrinters. This function will allow the application to search through all of the printers that are configured on the system. Important information can be queried from the printer as well in order to create a DC to it in CreateDC.

CreateDC

The CreateDC function creates a DC for a device using the specified name.

HDC CreateDC(
  LPCTSTR lpszDriver,        // driver name

  LPCTSTR lpszDevice,        // device name

  LPCTSTR lpszOutput,        // not used; should be NULL

  CONST DEVMODE *lpInitData  // optional printer data

);

The lpInitData, or DEVMODE structure is very important mainly to printer device contexts. This structure is also very complicated, however, since this article does not cover printing, that is all that will be said about DEVMODE.

CreateIC

The CreateIC function creates an information context for the specified device. The information context provides a fast way to get information about the device without creating a device context (DC). However, GDI drawing functions cannot accept a handle to an information context. This function should be followed by a call to DeleteDC when the information context is no longer needed.

HDC CreateIC(
  LPCTSTR lpszDriver,       // driver name

  LPCTSTR lpszDevice,       // device name

  LPCTSTR lpszOutput,       // port or file name

  CONST DEVMODE *lpdvmInit  // optional initialization data

);

Demonstration

The program that has been created to demonstrate the topics covered in this article will visualize the update region for the user. Other information will also be displayed in either the non-client area of the main window, or directly on one of the display drivers. One other feature of the demo application is to turn off the handling of the WM_ERASEBKGND message in order to see what effect is created.

Because of the multi-monitor testing, this application requires WIN98, WIN200 or above. This application is written in WTL, therefore the WTL header files will be required to build the source project. The WTL wrapper classes (CPaintDC, CWindowDC, etc...) will also be used in order to illustrate the use of each of the different DCs. This application will also require the version 5.0 header and lib files to compile because it uses the EnumDisplayDevices function which is only supported in WIN98 and WIN2000 or above.

Use if this application is very simple. Run the application, can force the main window to redraw itself. There are many ways to do this including:

• Maximize / Restore the main window
• Resize the window Horizontally / Vertically / Diagonally
• Drag something across the window to invalidate a new region
• Place a window in the center of the window then activate the demo app

All of these methods to invalidate the window should be viewed. Then each of these steps should be taken to view how things change with certain settings in the system.

• Modify the CS_HREDRAW / CS_VREDRAW styles in the view menu
• Modify the handling of the WM_ERASEBKGND message
• Change the Show Window Contents While Dragging option on the view menu.

Each time that a WM_PAINT region is received, the current update region for that window will be framed with a new color. This will allow the user to visualize the update region as each new WM_PAINT message occurs. There are a few style flags that can be set for the window that will demonstrate the effects that they have on WM_PAINT messages. Here are a few screen images of the visualized update regions:
 

Data Log

The data log contains the important and usable values of the PAINTSTRUCT structure. Here is an image of what the data bar looks like when it is active.

Here is a description of what each of the parameters will demonstrate:

• HDC: The value of the HDC that is allocated in WM_PAINT. Shows that a new HDC is created for each message,
• fErase: This shows whether the WM_PAINT handler is responsible for erasing the background or not. If WM_ERASEBKGND is set on the menu, then that message will be handled properly and fErase will appear as FALSE on the data bar. If WM_ERASEBKGND is not handled, then fErase will be TRUE. The view window does not handle WM_ERASEBKGND ever, so you will see a weird effect, it will look like the window is not updating properly, except for the update region will be framed properly.
• rcPaint: The four components of this rectangle will be displayed demonstrating the bounding rectangle of the update region on the window.

Selecting No Log on the menu will hide the data bar.

If Non-client is selected on the menu, then the data bar will be painted in the border area of the window. This is done to illustrate how painting can be accomplished in the WM_NCPAINT message handler and using the CWindowDC.

This program will enumerate up to two display devices on your machine, and add them to the view menu. If you select one of these items, then the databar will be displayed in the upper-left hand corner of the monitor that the display represents. The CreateDC function is used to create the DC with the device name for that monitor. This feature was added to demonstrate getting a DC to any display monitor.

CS_HREDRAW / CS_VREDRAW styles

As described earlier in the article, these styles affect the update region. If one of these styles is set, then when the window is resized the corresponding style may force the entire view to be redrawn rather than simply the new update region. Change this style, and watch the effect that is has on the update region.

WM_ERASEBKGND

If this option is set, then the application will process the WM_ERASEBKGND message, effectively clearing the background during each WM_PAINT message. However, if this item is unchecked, then the application will ignore the WM_ERASEBKGND message. This will have the effect of leaving whatever invalidated the region on top of the window, rather than refreshing the display.

Also notice the fErase field value in the data bar. When WM_ERASEBKGND is handled, then fErase is FALSE indicating that the WM_PAINT routine is not responsible for initializing the drawing surface. If WM_ERASEBKGND is not processed, then fErase in the PAINTSTRUCT will be true, informing the application that it should erase the background of the display before it paints, which this application does not do in order to demonstrate the process.

Show Window Contents While Dragging

This will toggle the setting in the display properties that forces the window to repaint while a window is begin dragged. Whether it is being resized, or another window is being dragged across the top of the window. The net effect of this option being set is that more paint messages will be generated, and the update regions will be smaller, but more frequent. This application should be viewed with this option on and off.

Here is an example of the difference when resizing the window.

 

Short comings

There are two minor short coming in this demonstration application when the databar is painted on one of the display adapters. The application does not try to erase or restore the previous data when the data bar is removed. This could have been fixed by caching the region where the data bar is painted, and restoring that region when the data bar is removed. However that would require memory DCs, and this article ignored their explanation.

When the data bar is displayed on one of the display adapters, but it is also painted onto a window from a different application, it may appear that the data bar has missed a region that is should have painted. This is actually caused by the other application receiving its WM_PAINT message after the data bar has been painted on top of it. This could be fixed by finding the window that is painting over the data bar and validating that region, or by windows hooks. However this option has been left unexplored.

Conclusion

The WIN32 paint architecture has been designed to paint windows and controls incrementally. This increases the performance and the appearance of applications. The incremental paint process is enabled by the update region that WIN32 maintains for each and every window. WM_PAINT messages are not pushed into the message queue by the system. Instead, WM_PAINT messages are only generated when all of the other messages from the queue are processed, and the window's update region is not empty. WM_PAINT messages should be handled with the BeginPaint API, or with a CPaintDC if MFC or WTL is used.

There are other types of common DCs that can be used to paint onto the window or one of the displays. Each type of DC has a special purpose. The client DC is is to paint on the client area of a window. Use the GetDC API, or the CClientDC class. A window DC allows an application to paint to the entire window. Use the GetWindowDC API, or CWindowDC class. The, GetDCEx is the API function that is at the root of all of the common DC functions. Each of the other common DCs can be created with a call to GetDCEx and the proper set of flags. If an application requires to paint directly on the desktop, then CreateDC can be used to create the DC for this purpose.

There are many different ways to paint a window in WIN32. This tutorial has presented many facts about the design, structure and process found in WIN32. Hopefully the reader can take these facts and apply them in ways that will increase the performance and appearance of his application.

You must Sign In to use this message board.

FAQ  Noise Tolerance Very HighHighMediumLowVery Low  Search Messages    Layout Expand All MessagesThread ViewNo Javascript (slow)No Javascript Preview    Per page 102550

Msgs 1 to 25 of 40 (Total in Forum: 40) (Refresh) FirstPrevNext

Mouse Click Event from IE using VC++ Dabara 19:31 1 Jul '08   Hi How to get mouse click event from java Script page from Internet Explorer ? I used IHtmlDocument::Onclick Mousemessage but I am able to get only Html page Mouse click Event not getting Java Script page Mouse click event . dabara Sign In·View Thread·PermaLink Re: Mouse Click Event from IE using VC++ Paul Watt 6:29 8 Oct '08   I am sorry, I do not see how this question relates to this article? Sign In·View Thread·PermaLink 5.00/5 (1 vote) How to get Update rgn in MFC theali 19:50 25 May '08   Hi Very nice articles for both Beginner and Intermediate. It provides very valuable info. I want to simulate the "UpdateRgn" example using MFC But failed as it works only for overlap of window but not for resizing window. Here is the code only i changed. void CMDIPAINTCHECKView::OnPaint() { CRgn cRgn; cRgn.CreateRectRgn(0,0,0,0); GetUpdateRgn(&cRgn); CPaintDC dc(this); // device context for painting CBrush brush; brush.CreateSolidBrush(0xFF00FF); CBrush brush2; brush2.CreateSolidBrush(0xFFFFFF); dc.FillRgn(&cRgn, &brush2); dc.FrameRgn(&cRgn, &brush, 4, 4); // Do not call CView::OnPaint() for painting messages } BOOL CMDIPAINTCHECKView::OnEraseBkgnd(CDC* pDC) { // TODO: Add your message handler code here and/or call default return TRUE;//CView::OnEraseBkgnd(pDC); } int CMDIPAINTCHECKView::OnCreate(LPCREATESTRUCT lpCreateStruct) { if (CView::OnCreate(lpCreateStruct) == -1) return -1; // TODO: Add your specialized creation code here HWND m_hWndClient = m_hWnd; LONG lStyle = ::GetClassLong(m_hWndClient, GCL_STYLE); // Strip the horizontal and vertical redraw styles. lStyle &= ~(CS_HREDRAW | CS_VREDRAW); ::SetClassLong(m_hWndClient, GCL_STYLE, lStyle); return 0; } and plz help me in understanding the role of scroll bars in painting? regards Ali VC++,COM ,C# Sign In·View Thread·PermaLink window paint dc reflected on screen toddma 11:09 9 Nov '07   when a window's paint handler paints to it's DC (from the PAINTSTRUCT or parameter to Paint(), the painting is reflected on the screen. This includes child windows. I'm missing something maybe, but how to override that DC, so that the window and child windows paint to my (memory) DC. I'd like to have my DC in the PAINTSTRUCT or Paint() parameter, so I don't have to go changing all child windows code. Then when they are all finished, I can blit from that DC somewhere else (like to the screen, printer, bitmap wherever). (or just for flicker free drawing). Can you point me in the right direction? thanks Todd. Sign In·View Thread·PermaLink Re: window paint dc reflected on screen Paul Watt 6:48 19 Nov '07   Hi Todd, I am sorry it has taken so long to reply to your question. Hopefully you have already found your solution, however if not, here is what you need to do to create a back buffer to reduce flickering. You need to create what is called a Memory DC. You use the function CreateCompatibleDC to do this. That function requires an existing DC. This DC will be the model DC that your new compatible memory DC will be based from. For instance, if you wanted to create a memory DC for a printer, then the DC that you give it will originate from the printer. But in this case, you simply want a backbuffer for a Window. Therefore, you can simply use the DC you got from BeginPaint, GetDC or whatever method you used to get your Window DC. After you create a compatible DC, you will need to create a bitmap object to select into the memory DC. This will act as the memory buffer and the memory DC acts as the interface to write to your buffer. The total sequence of events should look like this: // code to create a back buffer to reduce flicker. // call to get original DC. HDC hDC = ::GetDC(hWnd); HDC hMemDC = ::CreateCompatibleDC(hDC); RECT clientRect; // get the dimensions of your window. ::GetClientRect(hWnd, &clientRect); // create your bitmap to act as the memory buffer for your back buffer. HBITMAP hBmp = ::CreateCompatibleBitmap(hDC, clientRect.right, clientRect.bottom); // select the bitmap into the memory DC ::SelectObject(hMemDC, hBmp); // release the handle to the original DC. ::ReleaseDC(hWnd, hDC); At this point your memory DC, hMemDC, is ready to use any place that you would normally have use the regular window DC. Cache this dc, and when your WM_PAINT event occurs, you only need to do this: PAINTSTRUCT ps; HDC hDC = ::BeginPaint(hWnd, &ps); ::GetClientRect(hWnd, &clientRect); ::BitBlt(hDC, clientRect.left, clientRect.top, clientRect.right, clientRect.bottom, hMemDC, clientRect.left, clientRect.top, SRCCOPY); ::EndPaint(hWnd, &ps); When you are done with the back buffer, use this code to cleanup. // Delete the MemDC first, this releases the hold on the bitmap handle. If you // delete the bitmap handle first, it will fail. // alternatively, you can hold the original bitmap handle that is returned // from the call to SelectObject above. Then call SelectObject back into the // memDC to release the hold on hBmp. ::DeleteDC(hMemDC); ::DeleteObject(hBmp); I hope this code helps you. Again, I am sorry for the amount of time it took to respond. Regards, Paul Sign In·View Thread·PermaLink Very nice article code_discuss 16:58 7 Nov '07   you got my 5! Sign In·View Thread·PermaLink 5.00/5 (1 vote) Re: Very nice article Paul Watt 6:49 19 Nov '07   Thanks I am glad you liked it. With .Net and other techs out now, I am surprised people still find this relavent. Sign In·View Thread·PermaLink get existing DC hijacked from another thread/application? fldz 15:58 8 Oct '07   Newbee question: I want to get a DC from a browser window for OGL. (IE) Is there any maybe slightly low-level approach to stealing an existing DC that you can point me at? Flash uses ActiveX, is that the direction to study? I can overlay my DC by getting existing ActiveX window's RECT, but that's stupid. I can steal Flash's DC in Opera because Opera's plug-in will give me the process / instance(?) and (somehow, through my shameless kludgery) it works great! Sign In·View Thread·PermaLink border of client not displaying properly hdpc 7:39 6 Sep '07   Hi, Great article. I have a application that switches from wizard mode to advanced mode or vise versa via the menu. There are a few problem: 1 - If I start in the wizard mode, everything is fine (meaning non client and client are fine). Then switch to advanced it looks fine. Switch back to wizard it looks fine. Now switching to the advanced mode for the second the client does not display properly. But going back to wizard mode, is fine. Just going forth to advanced mode does not work. 2- If I start in advanced mode, it works fine but switching to wizard mode, it does not display properly. But switching back to advance is ok. The problem is the wizard mode does not display properly. Here are the two functions I have. I don't know if I am missing anything else. Thanks in advance for helping. wizard mode: void CMainDlg::OnWizard(void) { m_hWndClient = m_hWizardView; m_pWizardView->_Init(m_hWnd); // make so the frame is not resizable, get the style of the parent and remove resizable style and disable the maximize box LONG wndStyle = this->GetWindowLongW(GWL_STYLE); SetWindowLongW(GWL_STYLE, wndStyle & ~WS_SIZEBOX & ~WS_MAXIMIZEBOX & ~WS_MAXIMIZE); // get the current size of the window CRect rcCurrent, rcNew; rcNew.SetRect(0, 0, WINDOW_WIDTH, WINDOW_HEIGHT); GetWindowRect(&rcCurrent); // take the delta of the old window and the new one and start at that position rcNew.MoveToXY(rcCurrent.left + ((rcCurrent.Width() - WINDOW_WIDTH) / 2), rcCurrent.top + ((rcCurrent.Height() - WINDOW_HEIGHT) / 2)); MoveWindow(rcNew); RedrawWindow(NULL, NULL, RDW_FRAME | RDW_INVALIDATE | RDW_ALLCHILDREN | RDW_UPDATENOW); } advanced mode: void CMainDlg::OnAdvance(void) { m_hWndClient = m_hAdvancedView; m_pPropertySheetView->_Init(m_hWnd); // make so the frame is resizable, get the style of the parent and add resizable style and enable the maximize box LONG wndStyle = this->GetWindowLongW(GWL_STYLE); SetWindowLongW(GWL_STYLE, wndStyle | WS_SIZEBOX | WS_MAXIMIZEBOX); // send the message back to the window to same it the origninal size SendMessage(WM_SIZE, SIZE_RESTORED, MAKELPARAM(WINDOW_WIDTH, WINDOW_HEIGHT)); UpdateLayout(); RedrawWindow(NULL, NULL, RDW_FRAME | RDW_INVALIDATE | RDW_NOCHILDREN | RDW_UPDATENOW); } It seems that the border around the client area is not displaying properly. I am still learning to program. Thanks again for your help. Sign In·View Thread·PermaLink correction Jonnie White 22:18 3 May '07   Hi! Thanks for the great article. I noticed one small error: "Therefore, if an application simply wants to access the region that represents the client area of the window" should be "Therefore, if an application simply wants to access the region that represents the non-client area of the window" Greetings, Akame Sign In·View Thread·PermaLink Invalidate, vs Validate deville75 12:01 11 Apr '07   I'm not sure what these mean, but here is my guess. If a window becomes invalid, it will automatically be updated. If it is valid it does not need to be updated. So by manually invalidating a rectangle (InvalidateRect) I force the WM_PAINT message to be sent. Is this correct? What would ValidateRect do? Prevent the WM_PAINT to be called? ------------------------ Impossible is Nothing Sign In·View Thread·PermaLink What are //C: ??? toooobias 7:15 10 Apr '07   Hi Paul. it's a nice work you did, and it's very helpfull. But I still don't understand why you put the "C:" at the beginning of your commentary. Is it related with the use of WTL abstraction? Thx for Ur answer. Thomas Sign In·View Thread·PermaLink Re: What are //C: ??? Paul Watt 8:12 10 Apr '07   It is simply my commenting style. It has nothing to do with WTL. When I start programming I usually comment the logic first with psuedo code and comments. //C: Check for same name. //C: Update name. Then when I am done, I add the code, and I have precommented code. //C: Check if the name is different. if ( 0 != strcmp(pName, pValue)) { //C: Update name. pName = pValue; } Sometimes my comments go to more than one line, so the //C: also works to breakup separate thoughts. Sign In·View Thread·PermaLink PrintScreen deville75 6:01 14 Feb '07   I'm drawing a graph from a set of points that is being read on the fly. I need to be able to redraw the graph and add the new point. How do I take a screenshot and repaint it ? ------------------------ Impossible is Nothing Sign In·View Thread·PermaLink Erase Backgnd mfranco_neto 18:59 31 Aug '06   Hi, On a toolbar I am working on, the button is erased but it still responds to mouse clicks. I have already tried NOT to ANSWER the WM_ERASEBKGND; use BeginPaint-EndPaint, or GetDC-ReleaseDC instead, but the background is either erased or it is completely transparent and not drawn. Either way, the button does not show, but is active. Now, if I don't respond to WM_PAINT messages, the toolbar is correctly drawn, and the button is ok... Do you know what I should do? ThanX mfranco Sign In·View Thread·PermaLink 2.00/5 (1 vote) RedrawWindow Anonymous 1:48 29 Jun '05   Hey, thanx for the great article. I am trying to use the RedrawWindow api, with no luck. Basically im trying to make a class for desktop drawing, to draw directly to the screen, its being done in VB.net. I have managed to create a graphics object for drawing on the desktop, now my problem is redrawing the desktop, to remove the image. (Without clearing the entire desktop with a color, or a region.) This api is meant to be able to do it according to msdn, but i cant get it working... //from MSDN hWnd [in] Handle to the window to be redrawn. If this parameter is NULL, the desktop window is updated. // Public NotInheritable Class DesktopDrawer Private Sub New() End Sub Private Shadows Function Equals() As Boolean Return False End Function Private Shadows Function ReferenceEquals() As Boolean Return False End Function Private Declare Auto Function GetDC Lib "user32.dll" (ByVal hWnd As Int32) As Int32 Private Declare Auto Function ReleaseDC Lib "user32.dll" (ByVal hWnd As Int32, ByVal hDC As Int32) As Int32 Public Shared Function GetDesktopDC() As IntPtr Dim DesktopDC As Int32 = GetDC(0) Return New IntPtr(DesktopDC) End Function Public Shared oldGraphics As System.Drawing.Graphics Public Shared oldDC As IntPtr Public Shared Function GetDesktopGraphics() As System.Drawing.Graphics Dim DesktopDC As IntPtr = GetDesktopDC() Dim grp As System.Drawing.Graphics = System.Drawing.Graphics.FromHdc(DesktopDC) oldDC = DesktopDC oldGraphics = grp Return oldGraphics End Function _ Public Structure RECT Public Left As Integer Public Top As Integer Public Right As Integer Public Bottom As Integer End Structure 'RECT Declare Function RedrawWindow Lib "user32" (ByVal hWnd As Integer, ByVal lprcUpdate As RECT, ByVal hrgnUpdate As Integer, ByVal flags As Integer) As Integer Public Shared Sub RefreshDesktop() RedrawWindow(Nothing, Nothing, Nothing, Nothing) End Sub Public Shared Sub ReleaseGraphics() ReleaseDC(Nothing, oldDC.ToInt32) End Sub End Class Sign In·View Thread·PermaLink 2.00/5 (1 vote)