Lockwindowupdate Series 4: What operations should I use lockwindowupdate?

Now we know what kind of operations should use lockwindowupdate. Now let's take a look at how people mistakenly use this function in some work unrelated to drag and drop.

 

People can see that lockwindowupdate's "locked window won't be able to draw itself" behavior, and use it as a lazy way to use the wm_setredraw message, although sending a wm_setredraw message is no more troublesome than calling lockwindowupdate. It is only 20 characters long, and if you use the setwindowredraw macro in <windows. h>, it will be half.

Not used	Lockwindowupdate (hwnd)
Generation and use	Sendmessage (hwnd, wm_setredraw, false, 0) or Setwindowredraw (hwnd, false)

 

Not used	Lockwindowupdate (null)
Generation and use	Sendmessage (hwnd, wm_setredraw, true, 0) or Setwindowredraw (hwnd, true)

 

As we mentioned earlier, only one update window in the system can be locked at a time. If you call lockwindowupdate to prevent repainting of the window, for example, you do not want to refresh the window until the update is complete, disable the re-painting of the window. If you use lockwindowupdate, there will be numerous problems.

 

First, if another program uses lockwindowupdate in the same way, one of you will fail. First, the program that calls lockwindowupdate will succeed, and the second program that calls lockwindowupdate will fail. What are you going to do now? Your window will not be locked.

 

Secondly, if you lock your window update, then the user switches to another program and tries to drag an object (or even just try to move the window), The lockwindowupdate will fail, as a result, the user encountered a situation where the drag and drop failed due to some mysterious reason. Then, 10 seconds later, all functions will work properly. The "Stupid bad windows" User muttered.

 

Conversely, if you are about to call lockwindowupdate during a drag-and-drop or window movement, your call will fail.

 

This is just a more general example of using the Global Status to handle programming errors in local situations. When you want to disable the re-painting of a window, you do not want this to affect other windows in the system. Updating your own window is a local situation, but you use the global status (locked update window) to maintain it.

 

I can expect someone to say: "Then, the window manager should prevent people from locking in window updates in a non-drag-and-drop operation ." The problem is, how does the window manager know this? It only knows what happened, but does not know why. Does a program use lockwindowupdate because it is lazy to use the wm_setredraw message? Or in response to the user input that triggers the drag-and-drop operation? There is no way to say "the user presses down the mouse button", because the user may use keyboard-based and drag-and-drop equivalent operations (for example, using the direction key to change the window size ). Basically, this problem is hard to solve unless the computer can have more guesses about what he is doing.

 

Next is the final comment on lockwindowupdate.

 

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/22/1742084.aspx