CommandBarButton.Mask property deprecated in VS 2010

As you already know from my posts in the last months, VS 2010 will use WPF-based commandbars and will introduce support for 32-bit bitmaps with built-in transparency in the alpha channel for pictures of commands of add-ins, apart from the old way of using 24-bit bitmaps with RGB=0,254,0 for background color. While VS 2010 Beta 1 only supports the new way, I’ve been told that Beta 2 will support the old way for backwards compatibility.

Toolwindows in VS 2005 and higher have always supported either 32-bit bitmaps with built-in transparency in the alpha channel, or 24-bit bitmaps with RGB=255,0,255 as background color, and VS 2010 will support both too.

The third and last area problematic with custom pictures is when you want to set the picture of a CommandBarButton directly (not through a command). While some people use this approach to avoid satellite dlls, the only scenario where I personally use and would recommend this approach is to provide a context menu in some listview or treeview with menu entries that don’t have a command behind (because they are operations for the listview or treeview such as “add”, “edit”, “remove” items, not global operations). To make such context menu with a look & feel 100% consistent with Visual Studio I create a CommandBarPopup. I haven’t written yet an article to show this but the basic idea is to create a commandbar popup calling:

myCommandBarPopup = dte.CommandBars.Add(Name:="MyCommandBar", Position:=MsoBarPosition.msoBarPopup, Temporary:=True)

and then add CommandbarButtons calling:

myCommandBarButton = DirectCast(myCommandBarPopup.Controls.Add(...), CommandBarButton)

and then set the Caption, Picture and Mask properties:

myCommandBarButton.Caption = "..."

myCommandBarButton.Picture = ...

myCommandBarButton.Mask = ...

and then set-up an event handler for the Click event.

Notice that you have to provide a “picture” bitmap, which in VS 2005 and 2008 should be a 24-bit bitmap with any background color, and a “mask” bitmap which should use White=255,255,255 for the pixels that should be transparent color and Black=0,0,0 for the pixels that are actually colored in the “picture” bitmap. Since this has the inconvenience of being forced to provide two bitmaps per button, most people use a custom method to generate the mask image from the picture image.

This is not going to work in VS 2010, though. Since VS 2010 supports 32-bit bitmaps with built-in transparency in the alpha channel, Microsoft is making the CommandBarButton.Mask property deprecated (you get an exception if used). So, if your add-in for VS 2005 / 2008 uses the CommandBarButton.Mask property in one of the two scenarios that I have mentioned, you will need to revisit it and adjust it accordingly to make it work with VS 2010. Assuming that you want the same binary dll to work with VS 2005, 2008 and 2010, one approach is to design 32-bit bitmaps images with built-in transparency (for the VS 2010 version) and generate programmatically the 24-bit “picture” bitmap and the “mask” bitmap for the 2005 and 2008 versions. If your add-in only targets VS 2010, you no longer have to use the CommandBarButton.Picture approach to avoid the satellite dll since VS 2010 will get rid of satellite dlls for add-ins.

Microsoft fixing problem of grayscale disabled picture of add-in commands in VS 2010

The problem that always existed in Visual Studio with the generated grayscale picture for a disabled command of an add-in (or CommandBarButton without a command) is going to be fixed in Visual Studio 2010, according to the tests that I have done. That is, an add-in with a command that provides a 24-bit bitmap in a satellite dll with RGB=0,254,0 as background color (the old way compatible with VS 2005 / 2008) now shows a crisp and defined disabled picture if the command is disabled. Notice that providing a 32-bit bitmap with built-in transparency (the new way introduced in VS 2010) is not required to get this “fix”, it is something that Microsoft has fixed internally even for 24-bit bitmaps in the new WPF-based commandbars of VS 2010.

I have been unable to test if the same applies to CommandBarButtons whose picture is provided through the Picture property (without a command) but I think it will be fixed too.