Ran across a very interesting article, in the NYTimes magazine, about a line of inquiry into happiness, behavior and decisions.


The major psychological thrust was that we're not very good at predicting how we will feel after an anticipated event.  For example, we tend to underestimate how quickly we will adapt to that shiny new gadget (say, an LCD HDTV with native 1080p resolution).  In the other direction, we also tend to underestimate how quickly we will overcome adversity (e.g., a car accident).


The authors term this "impact bias"; impact because the subject is the duration and intensity of the feeling, bias because we tend to underestimate it.


The major economic thrust of the research is that we're not very good at predicting how we will behave during periods of anxiety, distress, etc...  The proponents broadly term these "hot states".  For example, mountain climbers that find themselves stuck w/o shelter in frigid temperatures may, under calmer circumstances, swear that they'll stop climbing the next time they're more than X feet away from shelter/food/camp only to find themselves breaking this promise the next time they're in a similar circumstance.  Climbing up a mountain will the sun is setting is the hot state; calm circumstances are the "cool state" and the variation in anticipated behavior (what we think we will do in a hot state) is often wide.


Very interesting research.  Another consideration that the researchers (Daniel Gilbert of Harvard, Psychology dept, George Loewenstein of Carnegie-Mellon, Economics dept, and a few others) and find is that the brain's adaptability doesn't seem to kick in until the intensity of the event is pretty high (either strongly positive or strongly negative).  So we underestimate how quickly we'll get over a car accident but overestimate how annoying a squeaky door or broken bed spring will be.


In one experiment the participants are allowed to choose from a set of pictures.  One group is told that their choices are final.  The other is told that they can exchange the photos a few weeks later.  The researchers find that the people who couldn't change photos were happier than those who could!  I believe they interpret this as an example of underestimate just how bothersome "buyer's remorse" or "missed opportunities" will feel.

Accessing .NET/C# objects from MFC COM

Turns out that accessing .NET objects from an MFC COM object is relatively straightforward.  The main steps are:
  1. Create a managed class.  It's best to explicitly implement an interface to avoid breakage due to versioning down the road.
  2. Attribute the managed class and its interface(s) with a Guid.  In the COM world GUIDs identify coclasses and interfaces.
  3. Register the managed dll with COM.  In visual studio this will take care of exporting the TLB and running regasm on the managed dll.
  4. To pass a class to an MFC COM object method, define the method as taking a pointer to IUknown.  Every automation object inherits from IUnknown.
  5. In C++, get a reference to the interface via CoCreateInstance().
  6. Call methods/access properties on the interface as needed!

For example, suppose you have a C# class TestClass in TestClass.dll and you want to call TestClass.TestMethod() from an in-process COM server implemented using MFC.  In COM the only way to access the functionality of a class is through an interface.  So you'll need to create an interface containing the methods you want to call and make TestClass inherit from that interface.

C# source:


public interface ITestInterface


void TestMethod();



ClassInterface(ClassInterfaceType.None)] // to
prevent interop from creating a class interface for you

class TestClass : ITestInterface


void TestMethod();


To make TestClass and ITestInterface from TestClass.dll visible to C++, the C++ source will need to import both the type library exported from the C#/Managed dll as well as mscorlib.tlb.  To do this, add the following import statements:

C++ .h header file:

#import "mscorlib.tlb"

#import "..\TestClass\bin\Debug\TestClass.tlb" //
created by tlbexp.exe or when visual studio project property "register for COM"
is true

To access TestClass.TestMethod() from C++ you'll need to get a reference to ITestInterface (which TestClass implements).  In COM, interfaces are the only way to access an objects functionality.

C++ .cpp source file (error checking skipped for clarity):

ITestInterface *tptr = NULL;

CoCreateInstance(CLSID_TestClass, NULL,
CLSCTX_INPROC_SERVER, IID_ITestInterface, (void**)(&cpi));


tptr->Release(); // COM uses reference counting
to figure out when to release memory

To pass TestClass to an MFC COM object method, you'll have to specify it's parameter type an IUnknown* (aka LPUNKNOWN).


DISP_FUNCTION_ID(CMyClass, "MyFunc", dispidMyFunc, 
MyFunc, VT_I4, VTS_UNKNOWN) // the vts_unknown ->

C++ method:

HRESULT CMyClass::MyFunc(IUnknown *pUnk)


ITestInterface *pti = NULL; // type
imported from TestClass.tlb

pUnk->QueryInterface(IID_ITestInterface, (void**)
(&pti)); // IID_ITestInterface also defined in

pti->TestFunc(); // calls the
managed method



This method can be called from C# as follows:

TestClass tc = new TestClass();

comObject.SomeFunc(tc); // assumes comObject
is an RCW around the MFC COM object you're passing TestClass to


Killing a remote desktop session remotely

Every so often someone (including me) leaves a remote desktop session (Terminal services session for some) open on a machine that only has licenses for 1 or 2 simultaneous desktop sessions.  A few useful commands in these situations:


To see who is on the server/find out their session id:

qwinsta /SERVER:


To kill a remote desktop session:

rwinsta /server:


The mnemonic looks like it's query winstation and remove winstation but that's just a guess.