Lockwindowupdate Series 1: What is the lockwindowupdate behavior?

Poor misunderstanding of lockwindowupdate.

This is the first article about the lockwindowupdate series. Lockwindowupdate is used to do something, and (and possibly more importantly) it is not used to do anything.

Lockwindowupdate is actually very simple. When a window is locked, all painting to it and its subwindows will fail. Instead of painting, the window manager remembers which part of the window the application is trying to draw. When the window is "Unlocked", these areas are invalid, so that the application gets a wm_paint message, thus, the synchronization between the screen content and the content that the application considers to be displayed on the screen is restored.

In cs_savebits, we have seen this behavior: "When the record is effective in case X, the application tries to plot it and does not process it if case X is no longer valid. In this sense, lockwindowupdate does the same bookkeeping work. This action occurs when you overwrite the locked window with a cs_savebits window, but no data is saved here.

The document clearly states that only one window can be locked at a time. At the same time, this can also be inferred from the function prototype. If the two windows can be locked at the same time, lockwindowupdate cannot be reliably used. What will happen when you do the following:

Lockwindowupdate (hwnda); // lock window
Lockwindowupdate (hwndb); // lock window B
Lockwindowupdate (null );//???

 

Third, what will lockwindowupdate be called? Unlock all windows? Is it true that only window a is unlocked or window B is unlocked? No matter how you answer the question, it is impossible for the following code to use lockwindowupdate reliably:

Void beginoperationa ()
{
Lockwindowupdate (hwnda );
...
}
 
Void endoperationa ()
{
...
Lockwindowupdate (null );
}
 
Void beginoperationb ()
{
Lockwindowupdate (hwndb );
...
}
 
Void endoperationb ()
{
...
Lockwindowupdate (null );
}

 

Assume that beginoperation starts an operation triggered by an asynchronous action. For example, assume that the operation draws the playback feedback, so it starts when the mouse is pressed and ends when the mouse is released.

It is assumed that the Operation B is complete while the video is still playing. Endoperationb cleans up Operation B and calls lockwindowupdate (null ). If you assume that this will unlock all windows, Operation A will be broken because it expects hwnda to be locked. Similarly, if you propose that you only unlock hwnda, not only operation a is damaged, but operation B is also damaged (because hwndb is locked even though operation B has been completed ). On the other hand, if lockwindowupdate (null) is recommended to unlock hwndb, consider the case where operation a is completed before operation B.

If lockwindowupdate can lock more than one window at a time, the prototype of this function needs to be modified so that the unlock operation can know that the window is being unlocked. There are many ways to do this, such as adding a new parameter or creating a separate function.

// Method A-New Parameter
// Flock = true lock, false unlock
Bool lockwindowupdate (hwnd, bool flock );
 
// Method B-Independent Function
Bool lockwindowupdate (hwnd );
Bool unlockwindowupdate (hwnd );

 

However, these two are not the actual situations. The lockwindowupdate function only locks one window at a time. The reason for doing so is clearer after understanding what lockwindowupdate is used.

 

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/19/1716211.aspx