Showing results for September 2014 - The Old New Thing

Do the math.

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 ...

There can be only one, but will it be you?

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 ...

Six out of ten is all you need.