ClientToScreen () is the conversion of window coordinates to screen coordinates Pwnd->getwindowrect (&RC); Gets the size of the entire form
Pwnd->getclientrect (&RC1); Gets the size of the customer area in the form
ScreenToClient () is to convert screen coordinates to window coordinates
The screen coordinates are relative to the upper-left corner of the screen, and the window coordinates are relative to the upper-left corner of the window user area.
VC, some functions use window coordinates, some use screen coordinates, use to distinguish.
A form is divided into two parts: the system area and the customer area
Like the title and menu is the system area, controlled by the system, customer area is your site!!!
Width, Height refers to the whole, clientwidth, clientheight refers to the client area, the two subtract is
The SYSTEM Zone!!!
ClientToScreen is to convert the coordinates from the current form to the screen!!!
ScreenToClient is the coordinates that convert the screen coordinates to the relative current form!!!!In the MFC dialog box program, if you want to get a rect of a control in a dialog box relative to the screen, you must define a control variable for the control and then call ClientToScreen through the control variable.
If you clienttoscreen directly inside the dialog class, you get a rect-sized piece of the upper-left corner of the dialog form . Space rect relative to the screen.
[CPP]View Plain copy print?
- Point
- is relative Clyhchxuview (temporarily understood as the screen) coordinates
- If you're going to get the coordinates of the upper left corner of the relative Clyhchxuview
- There is no need to convert
- If you're going to get the coordinates in the upper-left corner of the main window relative to the program
- you can count on that .
- void clyhchxuview::onlbuttondblclk (UINT nflags, CPoint point)
- {
- //todo:add your message handler code here and/or call default
-
- CRect RC;
- GetParent ()->getwindowrect (&RC);
- ClientToScreen (&point);
- Docx=point.x-rc.left;
- Docy=point.y-rc.top;
- Invalidate ();
- cview::onlbuttondblclk (nflags, point);
- }
Point is a relative clyhchxuview (temporarily understood as the screen) coordinates if you want to get a relative clyhchxuview the upper-left corner of the coordinate will not need to convert if you want to get the Relative Program main window upper left corner of the coordinates can be so void clyhchxuview::o NLBUTTONDBLCLK (UINT nflags, CPoint point) {//Todo:add your message handler code here and/or call default CRect RC; GetParent ()->getwindowrect (&RC); ClientToScreen (&point); Docx=point.x-rc.left;docy=point.y-rc.top;invalidate (); CVIEW::ONLBUTTONDBLCLK (nflags, point); }
Now let's see what Invalidate (TRUE) has done. In fact, it just indirectly adds a message queue to the WM_ERASEBKGND and WM_PAINT two messages. However, if you use Invalidate (FALSE), only the WM_PAINT message is generated, and there is no blinking
Now it seems that the flicker appears to have been generated by WM_ERASEBKGND news, in fact, it does have something to do with it. What did the Wm_erasebkgnd do? The WM_ERASEBKGND message is responded by the ONERASEBKGND () message handler function, which is to redraw the client area background . We can block this function by adding WM_ERASEBKGND to the project and then modifying the return statement to return TRUE in the overridden message handler, so the benefit is that the background will not be redrawn at this point and the background will not be erased.
It seems that there is no real reason, in fact the real reason is implied therein. Now for an experiment, try a quick blink and a slow blink, and you'll find that when you blink, we'll feel the black flash past, and the slow blink will feel like the whole process is continuous, nothing unusual. In fact, this is the blink of an image, that is, a number of discontinuous images of fast switching . There are three conditions, multiple and fast and discontinuous , and need to be in place to blink. If it is only two, it will only feel the mutation, not flicker, if the frequency is slow, it is equivalent to two images of the situation, and finally if it is a continuous image, it is like watching movies, smooth transition will not make people feel uncomfortable.
Knowing this, the next thing you can do is make a decision.
Solution :
With invalidate (FALSE), adding a WM_ERASEBKGND message handler function or a partial refresh is one of the three options that can solve the problem. All of them are to achieve the goal by removing the factor of the image discontinuity.
In addition, to say that the GDI BitBlt () function is and efficient, a single operation takes only a few to more than 10 microseconds, so we can use it with confidence, without worrying about any efficiency problems. However, compared to BitBlt (), StretchBlt () is much slower, about dozens of times times the difference.
There is the general drawing work is drawn on a buffer first, and then copied to the screen again.
Sometimes, when we need to take advantage of the flashing effect, but also can be through the rapid switching of multiple images to do, here we also will be two images of repeated switching to understand as multiple images.
ClientToScreen () and ScreenToClient ()