![]() ![]() The problem is, you see, that devenv.exe /resetaddin doesn’t remove permanent commandbars, only commands and buttons on commandbars. I think I forgot to blog about the resolution of this bug:ĭevenv.exe /resetaddin doesn’t fully reset the add-in If someone know the solution, let me know. So far I have been unable to solve this, I will post again if I find a resolution for this issue. When you cast the returned CommandBarControl to CommandBarButton you can use the Picture and Mask properties (COM IPictureDisp type) to set the image and the transparency mask, so there is much more room to play with the bitmap format, the color depth (32-bit, 24-bit, 8-bit), and how you get a COM IPictureDisp from a managed. In this scenario, there is no command, the CommandBarButton is created via. NET context menu to provide the same look and feel. The add-in creates a VS commandbar rather than a. CommandBarButtons created on a CommandBar created by the add-in to be used as context menu somewhere, for example in the context menu of a list (New, Remove, etc.).In this case the image of the button is actually the image of the command which in turn is supplied in a satellite dll in True Color (24 bit) bitmap format, so there is no much room to play… CommandBarButtons created from a command (via Command.AddControl).There are two scenarios where disabled buttons look bad: VS 2005 introduced True Color bitmaps (VS.NET 2003 used 16-color bitmaps) so it should be able to generate good-looking grayscale images as it does with its own pictures (if I am correct that the disabled image is autogenerated and not provided separately through some way not available to add-ins). ![]() I am now investigating why the grayscale image that Visual Studio 2005 / 2008 generates for a disabled button is so horrible/blurry for pictures of add-in commands and so crisp and precise for pictures of VS commands. I saw this approach too yesterday in this post of Roy Osherove.įortunately these hacks won’t be necessary in VS 2010, which will get rid of satellite DLLs for add-ins “officially”. While it may seem not very important a lacking command picture there, it happens that with that window open VS enters in a special mode that allows the user to drag the command on a toolbar to create a button, and the button would get the picture of the command. The picture of a command is something totally visible to the user when she clicks the “Tools”, “Customize” menu, “Commands” tab, “Add-Ins” section. I flagged that community content as “bug” because it doesn’t solve the fundamental problem, that is, providing a picture for the command, not just for its buttons. The implementation gets more complicated because those properties have the COM IPictureDisp type and therefore conversions from managed are required, and another creative technique is used to get the mask from a picture pixel by pixel rather than providing it directly (which would force to create two bitmaps per button). The basic idea is to give up the picture of the command, and to modify the picture of the CommandBarButton created from the command through its Picture and Mask properties. The first place where I saw it was in the very MSDN documentation about displaying a custom icon on the add-in button, in the Community Content section by Miguel Ferreira. And now I am seeing in several places an approach that developers of add-ins are using to avoid the satellite DLLs to provide custom pictures. For example, Microsoft has been too much creative in the last decade providing multiple tricky ways to solve the lack of transparency support in the original bitmap format. I *think* I've got the picture interface bit working, then.It always fascinates me how “creative” we the developers can be solving problems that shouldn’t exist in the first place. Alright, just poking at this offline a bit more. ![]()
0 Comments
Leave a Reply. |