Final remarks on LockWindowUpdate
Now that you understand the intended purpose of
LockWindowUpdate,
I'm going to tell you why you don't want to use it,
not even for its intended purpose!
You have to go back to the historical context in which
LockWindowUpdate was created.
Rewind back to 16-bit Windows, specifically Windows 3.1.
Back in these days, memory was expensive.
Video drivers were pretty limited in functionality.
There was no DirectX.
There was no AlphaBlend function.
All you had was a screen buffer.
The LockWindowUpdate function let you take
control over one window's portion of that screen buffer
so you could apply your fancy effects to the window
without that window's knowledge.
It's been over a decade since Windows 3.1,
and in the meanwhile, we gained DirectX overlays,
regional windows, layered windows, alpha blending,
desktop composition,
all sorts of cool graphical effects that weren't available
back in the old days.
In particular, those layered windows and regional windows
pretty much let you do nearly all of the stuff you would have wanted to
do with LockWindowUpdate anyway.
If you want to draw a highlight around a window,
you can position a regional window around it.
If you want to draw a drag image over a window,
you can just create layered window and position it over
the target window.
Give the layered window a region and whatever fancy alpha
channel you want, and let the graphics engine do the heavy
lifting of alpha blending and composition.
Even better, the layered window can extend outside the window
you are dragging over, something that
LockWindowUpdate can't do.
(You can see this effect in Windows XP if you do a "select all"
in an Explorer window and drag the entire selection around the screen.
Notice that the drag image is not constrained to the boundaries of
the window you are dragging over.)
What's more, in the exciting new composited world of Vista's
desktop window manager,
LockWindowUpdate is even less desirable.
Locking a particular window for update isn't so bad
since the desktop window manager can just give you the
backing bitmap for the window.
But if you lock the entire screen
(which I've seen may people do),
the desktop window manager needs to compose all of the
windows into an actual bitmap that it can give
you when you call GetDCEx with the
DCX_LOCKWINDOWUPDATE flag.
The desktop window manager does composition on the fly
with the help of DirectX and accelerated video drivers.
The result of all this composition normally goes straight
to the screen without actually residing in a "composited"
bitmap anyway.
But if you lock the screen and ask for a DC to it,
the desktop window manager needs to emulate the old
behavior and give you access to something that represents
what you would have gotten if there were no
composition in the first place.
That ain't cheap.
Epilogue. I'm not sure if this series was a success or not.
My goal was just to help people use LockWindowUpdate
more effectively and guide them towards alternatives when
LockWindowUpdate is the wrong tool for the job.
In other words, it's an article about LockWindowUpdate,
not function documentation.
I tried to keep the presentation light,
but I guess my jokes fell flat,
and people just used them as a springboard for negative comments.
And extra thanks to the people who took it as an opportunity to
complain about the documentation.
I mean, duh, if the documentation were perfect,
I wouldn't have written this series in the first place.
Though these people also neglected to read all of the
documentation; they looked only at the function description page.
There's more to documentation than dry function descriptions, people!
The function description is a reference; you go there when
you already know what's going on and you just need to fine-tune a detail.
The real learning happens in the overviews and articles.
If you want to learn how to operate your radio,
you don't read the schematic first.
I think Ronald D. Moore is really onto something when he says,
"You have to be tough enough to listen to the podcast."
