The Old New Thing

AttachThreadInput is like taking two threads and pooling their money into a joint bank account, where both parties need to be present in order to withdraw any money

Consider this code: // Code in italics is wrong foregroundThreadId = ::GetWindowThreadProcessId(::GetForegroundWindow(), 0); myThreadId = GetCurrentThreadId(); if (foregroundThreadId != myThreadId) { AttachThreadInput(foregroundThreadId, myThreadId, TRUE); BringWindowToTop(myWindowHandle); If you try to ...

Displaying a property sheet for multiple files

Today's Little Program will show a property sheet that covers multiple files, just like the one you get from Explorer if you multi-select a bunch of files and right-click them all then select Properties. In fact, that description of how you do the operation interactively maps directly to how you do the operation programmatically! #define ...

A big little program: Monitoring Internet Explorer and Explorer windows, part 3: Tracking creation and destruction

Last time, we listener for window navigations. Today we'll learn about tracking window creation and destruction. The events to listen to are the DShell­Windows­Events. The Window­Registered event fires when a new window is created, and the Window­Revoked event fires when a window is destroyed. The bad news is that the ...

Dispatch interfaces as connection point interfaces

Last time, we learned about how connection points work. One special case of this is where the connection interface is a dispatch interface. Dispatch interfaces are, as the name suggests, COM interfaces based on IDispatch. The IDispatch interface is the base interface for OLE automation objects, and if you want your connection point ...

An introduction to COM connection points

Last time, we saw how to enumerate all the Internet Explorer and Explorer Windows and see what they are viewing. But that program printed static information. It didn't track the changes to the windows if the user clicked to another Web page or navigated to a different folder. In order to hook that up, we need to understand the connection ...

A pathological program which ignores the keyboard, and understanding the resulting behavior based on what we know about the synchronous input

Today, we'll illustrate the consequences of the way the window manager synchronizes input when two or more threads decide to share an input queue. Since I need to keep separate state for the two windows, I'm going to start with the new scratch program and make the following changes: #include <strsafe.h> class RootWindow : public ...

When you share an input queue, you have to wait your turn

Now that we've had a quick introduction to asynchronous input, let's look at some of the details. Remember, this is a peek under the hood at how the sausage is made. The algorithm described here is not part of the API contract and it can change at any time, as long as it services the overall goal of serializing input. Let's start by ...