The MFC provides a framework-based printing and print preview feature code. Its basic idea is that the code combined with the actual display and print documents is one, that is, the onDraw (CDC * PDC) in the CVIEW associated with this document. The MFC framework is determined according to the user's operation to point to the screen or the printer, when the PDC points to the screen device, the document is displayed on the screen, and the document is printed when pointing to the printer device. These are very understanding, but when we want to print a preview, the PDC that passes in is a bit special. Because the print preview is made on the screen, it usually believes that the PDC that passes in this is also a type of screen DC. However, in fact, this PDC is constructed based on the current default printer's properties. For example, a printer is installed on my computer, its default printing paper is A4 size (210mm x 297mm), and its default resolution is 1200dpi. When the PDC in the cView :: overdraw function is the DC used to preview output, we call PDC-> getDeviceCaps (Horzsize), PDC-> getDeviceCaps (Vertsize), these two functions are used to get DC The size of the display area, in millimeters, the return value of 210 and 297, this happens to the size of the A4 paper. Then call PDC-> getDeviceCaps (Horzres), PDC-> getDeviceCaps (Vertres), which returns to the DC display area, but the unit is pixel (or point DOT), the result is 9917 And 14031. Let us see what the two values have related to 210 and 297 above. 1 inches is equal to 25.4 mm, then how many points can be accommodated according to the resolution of 1200DPI? Of course, is 210 / 25.4 × 1200, how much is calculated? That's right, it is about 9917 (actually 9921.259 ...), and 297 can be converted into 14031.
Now let's take a look at another problem. When we use MEMDC.CREATECMOMPALEDC (PDC) to create a function that is compatible with the PDC compatible memory DC, whether the value obtained by calling getDeviceCaps (HORZSIZE) is the same as the PDC? The answer is different. The values obtained by calling the above four functions of the memory DC are 320 and 240 (Windows generally fixed returns to these two values), 1024, and 768 (this is the resolution of the screen). If the PDC mapping mode is mm_lometric, is the MEMDC mapping mode as it? Still not the same. MEMDC mapping mode is the default mm_text when just created, not the PDC. Then do the following: PDC-> setmapmode (mm_lometric); MEMDC.SETMAPMODE (MM_LOMETRIC); after the same CRECT is dptolp, or LPTODP results? Still different, why is the same mapping mode, the result of the coordinate conversion is still different?
Let's figure out how Windows's mapping mode is going on. There are two regions for DC, a view called "Viewport", a "window" (Window, which is different from the normal display, just a concept). You can imagine "Window" as a logical drawing area, and the so-called logical coordinate system is based on "Window". Suppose it is a 20 × 20 rectangle with a DC (0,0) point, you can understand it in "window", but what is the unit of metrics? Then, according to the current mapping mode of DC, such as the current mode is mm_lometric, then the unit is 0.1mm, that is, we draw a rectangle of 2mm × 2mm size in this DC. "Viewport" is a concept that is closely linked to the actual display device. It corresponds to the actual output area, and the device coordinate system is based on its, and the metric unit is always pixels. The DC generates a rule guarantee a rule to a viewport in accordance with the properties of the viewport and the window. When we really want to display or print graphics, DC actually uses this rule to map the Window coordinate (logical coordinate) to the ViewPort coordinate (device coordinate), as for DC to convert 2mm line segment to how much pixel long We don't have to care, Windows don't need to care. CDC provides getViewportorg (), getWindoworg () to get the origin coordinates of ViewPort and Window (relative to an imaginary neutral coordinate system), and getViewPortext (), getWindowext () to get ViewPort and Window size (respectively based on them Measure unit). So what do DPTOLP and LPTODP do? In fact, it is very simple. Take the lptodp is to implement such an operation: XViewPort = (xwindow-oxwindow) × CXViewPort / CXWindow OxViewPort
YViewPort = (YWindow-OyWindow) × CyviewPort / CyWindow OyviewPort
DPTOLP is the counterputing of the above operations. Also take the PDC, MEMDC, the mapping mode is MM_LOMETRIC, the print settings are unchanged. For PDC calls GetViewportorg, get the VIEWPORT origin is (0, 0), size is 9917 × -14031 pixels (yes, it is negative, because MM_LOMETRIC is close to the Y-axis direction), the Window origin is (0, 0) The size is 2099 × 2970 (0.1mm); also gets the VIEWPORT origin of MEMDC is (0), the size is 1024 × -768 pixels, the Window origin is (0, 0), the size is 3200 × 2400 (0.1mm ). This can explain why the PDC and MEMDC coordinate conversion is different.
