In a previous article, we looked at the scenarios in which lockwindowupdate should be used, i.e., the dragging scene.
Today, we're going to take a look at some of the scenarios where lockwindowupdate is misused.
People see LockWindowUpdate's "Your locked window won't be able to redraw itself" behavior and use it as a lazy version of the WM SetRedraw message.
Although sending a WM setredraw message isn't actually much harder than calling lockwindowupdate. The number of characters you type increases by 20 characters, or half if you use the setwindowredraw macro in .
As we mentioned earlier, only one window in the system can be locked for updates at a time.
If you call lockwindowupdate with the intent of preventing the window from redrawing, for example, because you're updating it and don't want the window to keep refreshing until the update is complete, then simply disable redrawing on that window.
If you use LockWindowUpdate, you create a series of subtle problems.
First, if other programs abuse LockWindowUpdate in the same way, then one of you will fail. Whoever tries lockwindowupdate first will get it, and the second program will fail. Now what do you do?Your window is no longer locked.
Second, if you've locked the window for an update, and the user switches to another program and tries to drag an item (or even just tries to move the window!).), the attempt will fail, and the user is now in a drag-and-drop position that stops working for some mysterious reason. Then, ten seconds later, it started working again. "There's a bug in this Windows system," the user muttered.
Conversely, if you decide to call lockwindowupdate while doing a drag-and-drop or window-move operation, the call will fail. This is just a concrete example of a more general programming error that uses global state to manage local conditions.
When you want to disable redraw in one of the windows, you don't want this to affect the other windows in the system;This is the situation on the ground. But you're using the global state (the window that locks the update) to keep track of it.
I can already expect people to say, "Well, if someone doesn't do drag-and-drop, the window manager shouldn't let them lock the window for updates." But how does the window manager know?It knows what's going on, but it doesn't know why.
Is the program calling lockwindowupdate because it's too lazy to use the WM setredraw message?Or is it doing this in response to some user input that results in a drag-and-drop operation?
Note that you can't just say "okay, the mouse button has to go down" because the user may be performing a keyboard-based action, such as resizing a window using the arrow keys, which is equivalent to dragging and dropping.
The ethical problem is hard to solve, and expecting a computer to be able to infer it is a bit harsh.
Summary. So, if it's not for a drag-and-drop scenario, don't use LockWindowUpdate. There's a good chance you'll need this: setredraw.
At last. Raymond Chen's "The Old New Thing" is one of my favorite blogs, and it has a lot of little knowledge about Windows, which is really helpful for Windows developers. **with what operations is lockwindowupdate not meant to be used?》