Today's Little Program simulates pressing the Play/Pause
button on your fancy keyboard.
This might be useful if you want to write a program that converts
some other input (say, gesture detection) into media controller events.
One way of doing this is to take advantage of the
function,
since the default behavior for the
message is to pass
the ...
I left an exercise at the end of last week's article: "Why is the error raised only sometimes?"
COM subscribes to the principle that if no marshaling is needed, then an interface pointer points directly at the object with no COM code in between.
If the current thread is running in a single-threaded apartment, and it creates a COM object with ...
A customer was observing strange mutex ownership behavior.
They had two processes that used a mutex to coordinate access to
some shared resource.
When the first process crashed while owning the mutex,
they found that the second process somehow magically gained ownership
of that mutex.
Specifically, when the first process crashed,
the second ...
There are a few references to the dialog style scattered throughout MSDN, and they are all of the form "Don't use it." But if you look in your copy of , there is no sign of anywhere. This obviously makes it trivial to avoid using it because you couldn't use it even if you wanted it, seeing as it doesn't exist.
"Do not push the red button on the ...
Today's Little Program merely prints a message whenever the
user changes the selection on the desktop.
I chose the desktop for expediency,
since it saves me the trouble of coming up with a way for the
user to specify which Explorer window they want to track.
Also, all I do is print a message saying "Selection changed!";
actually getting the ...
Consider the following interface declaration in an IDL file:
The idea here is that you want to be able to call the
method as
if you don't want to provide a reason.
If you try this, you'll find that the call sometimes fails with
error
0x800706F4, which decodes to
.
What's going on here?
The attribute does not mean what you think it means...
An oft-overlooked detail of the
and
methods
is the position of the stream pointer when the result is a stream.
These rules are
buried in the documentation,
so I'm going to call them out louder.
Let's look at
first.
If
returns a stream,
then the stream pointer must be positioned at the
end of the stream before the stream is returned.
In ...