If you are subscribed to the RSS of this blog, chances are that you are an add-in developer, because despite its title, I don’t write very much about macros (nobody really uses them) and I don’t know about SDK packages, only a little about how to call SDK services from an add-in. So, if you are an add-in developer, you must know how difficult is to get custom, transparent pictures on add-in buttons.
I have tried with Microsoft to get this fixed in the last years publicly and privately to no avail, but I keep pushing 🙂 and now that they are changing the commandbars to WPF is the best chance to get this fixed forever. Just in case you haven’t tried yet, you can’t get transparent pictures in VS 2010 Beta 1, neither using native (C++) satellite DLLs nor using managed (.NET) satellite DLLs (I tried managed DLLs after opening the bug report).
The short story (call to action):
Go to this page and vote to get this problem fixed (I am thinking that if it gets some hundreds of votes maybe they will fix it):
The long story (my last internal e-mail to Microsoft some days ago):
I would like to call the attention of all the people inside the Visual Studio Shell team that can make something to fix this problem that lasts 12 years now: it is very difficult to provide custom, transparent, pictures in buttons (CommandBarButton) created from add-ins:
– In VB5 (1997), VB6 and VBA you had to use the CopyFace/PasteFace methods to put custom pictures. The use of clipboard is causing problems today with remote desktop tools that monitor the clipboard.
– VS.NET 2002 forced to create a native (C++) resource library where the background color have to be almost green RGB = 0, 254, 0. The picture for ToolWindow.SetTabPicture have to use also that background color.
– VS 2005 allowed managed (VB.NET/C#) resource libraries, but you have to use also that color, or maybe magenta RGB=255,0,255.
– VS 2010 has again problem with transparency as I have reported here (neither almost green nor magenta works, at least with native satellite DLLs):
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=461192
The problems are two:
– There should no need to use resource libraries.
– The transparency should be much easier.
A very simple solution that solves both problems is:
– To allow to use icons, rather than bitmaps. Icons do support transparency natively.
– To provide a EnvDTE100.Commands3.
AddNamedCommand3 method with this signature:Function
AddNamedCommand2(ByVal AddInInstance As EnvDTE.AddIn, ByVal Name As
String, ByVal ButtonText As String, ByVal Tooltip As String,
Optional ByVal Icon As System.Drawing.Icon,
Optional ByRef ContextUIGUIDs As Object( ), Optional ByVal
vsCommandStatusValue As Integer = 3, Optional ByVal CommandStyleFlags
As Integer = 3, Optional ByVal ControlType As
EnvDTE80.vsCommandControlType = 2) As EnvDTE.Command.The same for the current Window.SetTabPicture(object): Make it to accept a Systen.Drawing.Icon with transparency.It would be up to the developer the decission to get this icon from a resource library, an embedded resource in the own add-in dll, a ImageList, a Picture control, a file on disk, an icon in memory, or whatever.
Then, internally in VS, make whatever you need to do with the icon:
transform it to a bitmap, transform the transparent color to green,
magenta or whatever, and paint it with transparent background.
Now that you are changing the commandbars to WPF and we are in Beta 1, it would be the best chance to get this fixed for good.
I have reported this twice through Microsoft Connect last years, to no avail:
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=336868
If you still feel that the current implementation that you offer to people extending Visual Studio with add-ins to use custom, transparent pictures in their add-ins is not so bad, then be 100% fully coherent and modify the add-in wizard to create a solution with:
1) The add-in project
2) A satellite DLL project with a custom, transparent, picture
and make it work just pressing F5 to debug the add-in. If it is quite difficult, then it means that the current implementation is not so acceptable after all. But it is too easy to ignore the problem and make the add-in wizard to create only the add-in project, without the satellite DLL, and use the parameter values MsoButton=True, Bitmap=59 to use the smiley face from the Office bitmaps rather than using a custom picture.
With best regards,
Carlos Quintero