Now we know the lockwindowupdate behavior. Now let's take a look at what it is used.
In fact, the design intent of lockwindowupdate can be expressed in one word: drag and drop. But we will talk about it later.
Lockwindowupdate is designed to allow a program
Temporarily take over the work of drawing the window. To do this, you certainly need to prevent window functions (or anyone else) from performing their normal painting activities; otherwise, the code at the two points (the code for normally drawing the window and the Code for attempting to take over the drawing) will compete for control of the window. Because they do not know what the other party is doing, the final result will be a mess.
However, if you have locked the update of the window, how can you draw it in the window? You can use the dcx_lockwindowupdate flag in the getdcex function. This flag indicates that "even if the window is locked, let me draw it above ". Of course, this flag can be passed only when the code that locks the window is locked. Otherwise, lockwindowupdate attempts to solve the class conflict at first.
Because people like to read tables, I made a table to summarize the changes that occurred when a window was locked for update.
|
Normal Behavior |
Update locked |
| Beginpaint,Getdc,Wait... |
Draw operations to draw on the window |
The painting operation did not plot anything in the window, but the affected areas were recorded for the backend to be invalid. |
| With dcx_lockwindowupdateFlagGetdcex |
(Do not use) |
Draw operations to draw on the window |
In other words, when a window update is locked, the ability of the common DC acquisition function (beginpaint and its partners) to draw to the window is denied and assigned to getdcex (dcx_lockwindowupdate ). NOTE: If no update window is locked, do not use the dcx_lockwindowupdate flag. The purpose of this flag is to point out that "I am the guy who called lockwindowupdate. Let's get started !"
The window manager has a bit like a comedy plot. You told the guard that "no one is allowed to enter this room ." You will be back in an hour. The guard won't let you in. "Sorry, sir, I cannot allow anyone to enter this room ." "But I am the one who tells you not to let anyone in ." "Yes, sir, I did it according to your instructions. No one can enter this room ." The error lies in the Command originally issued to the guard. You should say, "no one except me is allowed to enter this room ." Dcx_lockwindowupdate is like saying to the window manager, "it's me. Let me in ."
If you look back at the working method of the lockwindowupdate function, you will find that if a locked window does not try to draw any, then when the window is unlocked, no areas will be invalid. Although the cs_savebits window properties will automatically save the original pixels when the window is removed from the screen and restore these pixels, lockwindowupdate will not do anything similar. You need to take responsibility for making sure that you modify the pixel when the window is locked for update, and restore the original value after lockwindowupdate (null) is called. This usually saves the original pixels to a bitmap outside the screen before you do your own drawing operations, and then draws them back after you finish.
Well, the following is how to use the intent:
- When you want to take over the painting of another window, call lockwindowupdate for that window.
- Save the pixels of the window to be overwritten.
- Draw new pixels (These pixels are often the correction of the original pixels. For example, when you drag an object to the top of a window, you may add an image indicating the object ).
- As long as your operations are still in progress, despite repeated operations. (In this case, if the screen area you are modifying is different from the previous modification, you may need to "Back up" more pixels on the screen. You can perform Incremental backup/restoration. For example, you do not need to accumulate the pixel set to be restored before creating a new image. You only need to restore all the saved pixels to the screen, and then calculate the new position of the dragged image, save the pixels at the new location, and then draw a new image at the new location. In this way, you only need to process a group of "backup pixels ")
- After the operation is complete, restore the original pixel and call lockwindowupdate (null ).
In the next article, we will see more content about the word "drag", so that it is closely bound with the entire lockwindowupdate concept.
Although we have just started to discuss lockwindowupdate, you should be enough to handle this issue.
(Note: the purpose of writing this series is to describe the intention usage of lockwindowupdate, not to discuss whether this is a good design first)
Lockwindowupdate Series 1: What is the lockwindowupdate behavior?
Lockwindowupdate Series 2: How is lockwindowupdate intended to be used?
Lockwindowupdate Series 3: What operations should I use lockwindowupdate?
Lockwindowupdate Series 4: What operations should I use lockwindowupdate?
Lockwindowupdate Series 5: final comment on lockwindowupdate
Source: http://blogs.msdn.com/oldnewthing/archive/2007/02/20/1726880.aspx
