VC/MFC's Hdc,cdc,cwindowdc,cclientdc,cpaintdc Detailed:

Tag: des color io using SP file data on code

VC/MFC's Hdc,cdc,cwindowdc,cclientdc,cpaintdc Detailed:

First of all, what is a DC (Device description table)

Solution: A Windows Application draws graphics on the "canvas" of the logical meaning of the DC representation by creating a device description table for the specified device (screen, printer, etc.). 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.

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 to manipulate the device description table to work, such as a display, a printer, and a window client area associated with a display description 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.PaintDC: Encapsulates BeginPaint and EndPaint two API calls.

(1) Used to respond to window redraw messages (WM_PAINT) is the drawing output.

(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 output for the client area, associated with a particular window, allows the developer to access the client area in the target window, which contains the GETDC in its constructor, and the destructor contains the ReleaseDC.

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.

The CDC provides two functions, getlayout and setlayout, to reverse the layout of the device description table. Designed for the convenience of Arabic, Hebrew writing cultural habits, as well as the layout of fonts in non-European tables.

The CDC contains two device description tables, M_HDC and M_HATTRIBDC correspond to the same device, CDC specifies all output GDI calls for M_HDC, and most of the GDI property calls are controlled by M_HATTRIBDC. (for example, GetTextColor is a property call, and SetTextColor is an output call.) ）

Here are some simple code to see if you use these classes

HDC use, each draw line and other operations are not MFC encapsulated class more than an HDC parameter

In which device description table operation is performed

HDC Hdc=::getdc (m_hwnd);//m_hwnd = = This->m_hwnd the current window handle

Movetoex (Hdc,m_ptorigin.x,m_ptorigin.y,null);

LineTo (HDC,POINT.X,POINT.Y);

:: ReleaseDC (M_HWND,HDC);//Must be paired with GetDC

You can see the use of HDC more cumbersome, and if:: GetDC and:: ReleaseDC unworthy of the words, will cause errors

CDC *pdc=getdc ();

Pdc->moveto (M_ptorigin);

Pdc->lineto (point);

ReleaseDC (PDC);

CCLIENTDC DC (this);

dc. MoveTo (M_ptorigin);

dc. LineTo (point);

CWINDOWDC DC (this);

CWINDOWDC DC2 (GetDesktopWindow ());//Get a handle to the entire desktop, some desktop effects programs use

dc. MoveTo (M_ptorigin);

dc. LineTo (point);

CPAINTDC DC (this);

dc. MoveTo (M_ptorigin);

dc. LineTo (point);

You can see that MFC classes are easy to use because they are both in constructors and destructors that call the function of the response to get and release the DC.

Here are some of the finer points of knowledge

CCLIENTDC,CWINDOWDC The difference is not big, can say CWINDOWDC contains cclientdc take Notepad for

CClientDC is just white. The area where we can edit the text is the customer area

CWINDOWDC In addition to the above-mentioned white area, also includes menu bar and toolbar, etc.

The difference between CCLIENTDC and CWINDOWDC and CPaintDC is bigger.

In terms of DC acquisition, CCLIENTDC and CWINDOWDC use and can only be GetDC and ReleaseDC

CPaintDC is used and can only be beginpaint and EndPaint.

CPaintDC can only be used in response to WM_PAINT events

CCLIENTDC,CWINDOWDC can only be used in response to non-WM_PAINT events

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.

VC/MFC's Hdc,cdc,cwindowdc,cclientdc,cpaintdc Detailed: