DC,CDC and hDC in MFC

The Device Description table (DC) is a data structure in Windows that contains all the description fields that GDI needs about the display interface, including connected physical devices and various state information.

Graphics display function is done by the graphics card, you want to use the graphics display graphics function to complete your graphics output, how to do, give you a piece of hardware to use it? OK, now the manufacturer gives you a driver, give you some of the interface of the call, you can access it. But this kind of access is in the drive layer, very troublesome, more trouble is, each manufacturer to their own graphics card to provide the driver is not the same, then we write the graphics output program is not to change the machine (different graphics card) to be modified, a word: tired, two words: trouble. Now a savior has come, Bill, and he let his brothers implement an abstraction layer on top of the driver, and of course it can be thought of as a middle-tier software code (which we call the device context, also called the Device Description table DC), which is handled by these codes and drivers (of course, These drivers support the Windows platform). Then he encapsulates this implementation into a dynamic-link library that we can use to expose API functions through a dynamic-link library (see the next half of the VC), get a handle to this implementation (which can be said to be a resource), a handle to the device context (HDC), take advantage of this handle, It is like having access to the key that is implemented in this, and then you can ..., the rest of the reference to the contents of the upper half of the VC.

The Device Description table DC is a data structure that defines a set of graphical objects and their properties, affecting the output. Windows provides a Device description table for interacting between applications and physical devices, providing platform-agnostic application design. A Device description table is also called a device context, or a device environment.
A Device description table is a data structure that includes information about the drawing properties of a device, such as a display and a printer. All drawing operations are performed through the device description table. The device description table differs from most WIN32 structures in that the application cannot directly access the device Description table, and can only be accessed indirectly by a variety of related API functions through the handle (HDC) of the device description table.
The Device description table is always associated with a system hardware device. For example, the screen Device description table is related to the display device, the printer Device description table is related to the printing device and so on.
Screen device Description table, generally we simply call it a device description table. It has a certain correspondence with the display device, which, under the Windows GDI interface, is always related to a window or to a display area on the window. Usually the window device description table, generally refers to the window of the client area, not including the title bar, the menu bar occupies the area, and for the entire window, its Device Description table strictly speaking should be called the Window Device description table, it contains the full display area of the window. The method of operation is exactly the same, the difference is only the scope of operation is different.

Once the Windows window is created, it automatically produces the corresponding Device description table data structure, which allows the user to implement GDI Operations on the window display area, such as scribing, writing text, drawing bitmaps, filling, etc., and all of these operations are performed through the device description table handle.

To say the device description table, you must first say GDI (Graphics device interface). We can use these GDI functions to "draw" and "write" on programs by displaying graphics or text on the program window. The Device Description table (DC) is actually a data structure stored within GDI. Some of the values in the Device description table are graphical "properties" that define how some GDI functions work, such as: text color, picture fill, and so on. HDC is a type of device descriptor table handle that can be simply understood as a pointer, and is defined as a 32-bit unsigned integer.

Transfer from: http://longzxr.blog.sohu.com/187934817.html

DC (Device Description table): A Windows application draws graphics on the "canvas" of the logical meaning that the DC represents by creating a device description table for the specified device (screen, printer, and so on). A DC is a data structure that contains device information that contains the various state information required by a physical device. The WIN32 program needs to get the DC handle hdc before drawing the graph and release it when it is not in use.

Classes such as HDC,CDC,CCLIENTDC,CPAINTDC,CWINDOWDC are often seen in C + + programming.

HDC is a handle to a DC, and a pointer-like data type in the API.

The CDC is a class of MFC's DCs.

Device classification, such as CDC, contains a member variable for a class: M_NHDC; a handle to the HDC type.

Inherited views of the CDC and its derived classes:

CObject
Public |------CDC
Public |------|------CCLIENTDC
Public |------|------CPAINTDC
Public |------|------CWINDOWDC
Public |------|------CMETAFILEDC
(Note: Three derived classes other than CMetaFileDC are used for graphical drawing.)

The CDC class defines a device description table-related class whose objects provide member functions for manipulating device description tables to work, such as displays, printers, and display descriptions

The window client area associated with the table.

All drawing operations can be done through the CDC member function. CDC provides member functions for basic operation of device description tables, using drawing tools, selecting type-Safe graphics device structure (GDI), and color, palette. In addition, member functions are available to get and set drawing properties, mappings, control viewports, form ranges, transform coordinates, area operations, cuts, dashes, and draw simple shapes (ellipses, polygons, etc.). member functions also provide drawing text, setting fonts, printer swap, scrolling, processing meta-files.

Its derived class:

1.CPaintDC: Encapsulates BeginPaint and EndPaint two API calls.
(1) The drawing output used to respond to the window redraw message (WM_PAINT).
(2) CPaintDC calls BeginPaint () in the constructor to get the device context, and in the destructor, call EndPaint () to release the device context. EndPaint () is responsible for purging the WM_PAINT message from the message queue in addition to freeing the device context. Therefore, when processing a window redraw, you must use CPAINTDC, otherwise the WM_PAINT message cannot be purged from the message queue, causing a continuous window redraw.
(3) CPaintDC can only be used in WM_PAINT message processing.
2.CClientDC (client area device context): Handles the related form client area of the display description table.

The GETDC function is called automatically at construction time, and the ReleaseDC function is called automatically when the destructor is refactored. Generally applied to the drawing of the client Area window.

When you need to deal with a mouse click, and then immediately draw a circle, you can not wait until the next WM_PAINT message arrives before drawing, but immediately, it is necessary to CCLIENTDC. It can create a customer area outside of OnPaint DC

void Cmainwindow::onlbuttondown (UINT nflags, CPoint Point)
{
CRect rect;
GetClientRect (&rect);

        cclientdc dc  (This) ;
        DC. moveto  (rect.left, rect.top);
        DC. lineto  (rect.right, rect.bottom);
        DC. moveto  (rect.right, rect.top);
        DC. lineto  (rect.left, rect.bottom);
    }

3.CWindowDC: Handles the entire form region associated with the display description table, including frames and controls (subforms).
(1) Drawings can be drawn in the non-client area, and CCLIENTDC,CPAINTDC can only draw graphics in the customer area.
(2) The coordinates origin is in the upper left corner of the screen, and the CCLIENTDC,CPAINTDC coordinates origin is in the upper left corner of the client area.
(3) Associate a specific window that allows the developer to draw on any part of the target window, including boundaries and headings, which are sent along with the Wm_ncpaint message.

4.CMetaFileDC: The Device Description Table association associated with the meta-file.

Here are some of the finer points of knowledge
1, CCLIENTDC,CWINDOWDC difference is not big, can say CWINDOWDC contains CCLIENTDC. With Notepad, CClientDC is just the area where we can edit the text, the customer area, CWINDOWDC in addition to the area mentioned above, including the menu bar and toolbars.

2, CClientDC and CWINDOWDC and CPaintDC difference, in the acquisition of DC CCLIENTDC and CWINDOWDC use is and can only be getdc and ReleaseDC. CPaintDC is used and can only be beginpaint and EndPaint.

3. CPaintDC can only be used in response to WM_PAINT event CCLIENTDC,CWINDOWDC can only be used in response to non-WM_PAINT events

4, about the WM_PAINT event
The system sends WM_PAINT messages at various times: when a window is first created, when the window is resized, when the window is moved from behind another window, when the window is maximized or minimized, and so on, the actions are managed by the system, and the application simply receives the message passively. Draw operations in the message handler, and most of the time the application needs to be able to actively trigger the drawing operations in the window, such as when the data of the window display changes, this is usually done by the invalidaterect and INVALIDATERGN functions. InvalidateRect and INVALIDATERGN Add the specified area to the window's update region, and the system automatically generates a WM_PAINT message if the window's update zone is not empty when there is no other message for the application's message queue.

Why is the system not sending WM_PAINT messages when calling invalidate? Why do I have to wait until the app message queue is empty to send WM_PAINT messages? This is because the system treats the drawing operations in the window as a low-priority operation, so as to be pushed backwards as much as possible. However, this also helps to improve the efficiency of drawing: Two WM_PAINT messages between the InvalidateRect and Invaliatergn to invalidate the area will be added up, and then in a WM_PAINT message is updated once, It not only avoids updating the same area multiple times, but also optimizes the app's update operations. such as this through InvalidateRect and invalidatergn to invalidate the window area, depending on the system at the right time to send the WM_PAINT message mechanism is actually an asynchronous way of working, that is, in the invalid window area and send Wm_ There is a delay between the paint messages, and sometimes this delay is not what we want, and we can certainly use SendMessage to send a WM_PAINT message after the invalid window area to force immediate redrawing, but instead of using Windows GDI provides us with more convenient and powerful functions: UpdateWindow and RedrawWindow. UpdateWindow checks the window's update region to send the WM_PAINT message when it is not empty; RedrawWindow gives us more control: whether to redraw non-client areas and backgrounds, whether to always send WM_PAINT messages regardless of the update Whether the region is empty or not.
5. HDC and CDC convert each other:

(1), HDC to CDC conversion:
Method One: This method does not destroy the original resource at the end of the device (i.e.: HDC,HBITMAP)
CDC *PDC = Cdc::fromhandle (HDC);

Method Two: This method destroys the original resource at the end of the device (i.e.: HDC,HBITMAP)
CDC DC;
dc. Attach (HDC);

(2), CDC to HDC conversion:

CDC DC;

HDC hdc;

HDC = DC. GETSAFEHDC ();

6, first: CDC can not be released. FromHandle is a CDC object created through HDC to facilitate operation, freeing the DC should be directed to HDC instead of this CDC, and if it is released Pdc->releasedc it will be a hidden hazard.
HDC hdc = GetDC (HWND);
CDC *PDC = Cdc::fromhandle (HDC);
The two are points to a DC object that can only be freed once, and this release should target HDC rather than the PDC.

Then: GetDC and ReleaseDC call match, CreateDC and DeleteDC call match. GetDC is to get the existing DC from the window, and CreateDC is to create the DC, so the role of ReleaseDC and DeleteDC one is to release and one is to destroy.

Reproduced:

http://blog.csdn.net/yam_killer/article/details/7661449

DC,CDC and hDC in MFC