Back in the late night saddle; ISelectionContainer

Here I am again at 1:00am, working.  Now, I know you may think that 1:00am is early, but consider the fact that I get up at 6:30am to get the whole thing going and it's just crazy how many hours of sleep I am NOT getting.

But that is life when we're all trying to get Whidbey Beta 1 ready for customers to try.

ISelectionContainer and Managed implementations thereof...

The VSIP Docs cover this, but they don't go into details about how this works in VSIP Extras.  First there is the ISelectionContainer interface that an object must implement in order to be placed into the 'selection'.  For native code, it is simple to implement this interface as defined in the native designer.idl file. 

The problem comes when managed objects want to play in the Property Browser.  If they just implement the ISelectionContainer as defined in the Microsoft.VisualStudio.Shell.Interop namespace, they'll work fine with some VS components, but the PropertyBrowser won't work.  The reason for this is that the Property Browser is itself managed code.  Normally you'd think that a managed object implementing ISelectionContainer would work well with a managed object like the Property Browser, but there's something subtle here.

The Property Browser was written before the interop assemblies as they shipped in VSIP Extras.  The managed definition the Property Browser expects is actually inside a managed assembly that isn't documented and isn't supported for 3rd parties to interact with. 

We solved this problem for you in VSIP Extras by providing a SelectionContainer class in the Microsoft.VisualStudio.VSIP.Helper namespace.  This object implements both definitions of ISelectionContainer so that native VS code can interact with the object and the managed Property Browser can too.  When each asks for their respective interfaces (the same in one sense, but technically different in the managed world) they get the right one and use it.  The underlying implementation adapts the object to either interfaces.

This is a pattern you'll see often in VSIP in the future as we expose more and more functionality for things that have multiple definitions.  Unfortunately there are sometimes things that ship before we get to them to unify all the interfaces under one definition..  When that happens we can employ this pattern to satisfy all the callers of the interfaces and have them interact with the same underlying object.

The VSIP Extras download includes the source code for this in SelectionContainer.cs.  Take a look for the details.

Skip to main content