How to detect Visual Studio 2012 theme changed using IVsBroadcastMessageEvents

In this post I showed an approach using an invisible form to trap the WM_SYSCOLORCHANGE message that is fired when VS 2012 changes the current theme (from Dark to Light or viceversa). Don’t miss the comment in that post  where Sean points how to do it for packages using the IVsShell and IVsBroadcastMessageEvents interfaces. You can use that approach in an add-in too since you can get services as I explained in the article:

HOWTO: Get a Visual Studio service from an add-in
http://www.mztools.com/articles/2007/mz2007015.aspx

I have tested it today and it works like a charm.

MZ-Tools Articles Series: HOWTO: Create a setup for an add-in for the VBA editor of Microsoft Office for the current user (not requiring admin rights) using Inno Setup.

This new article shows a sample of a setup for an add-in for the VBA editor of Microsoft Office using InnoSetup. In this sample I show two interesting techniques:

HOWTO: Create a setup for an add-in for the VBA editor of Microsoft Office for the current user (not requiring admin rights) using Inno Setup
http://www.mztools.com/articles/2012/MZ2012019.aspx

MZ-Tools Articles Series: INFO: Registry entries to register an add-in for the VBA editor of Office for the current user without admin rights.

Continuing with the tutorials that I am writing about creating add-ins for the VBA editor of  Microsoft Office with Visual Studio and the .NET Framework, a new interim article between the last ones with sample code and the next ones that will come with sample setups:

INFO: Registry entries to register an add-in for the VBA editor of Office for the current user without admin rights.
http://www.mztools.com/articles/2012/MZ2012018.aspx

This article provides the solution to two common issues with add-ins of the VBA editor: “How can I install an add-in without admin rights?”, and “After installing the add-in, I don’t see it”.

MZ-Tools Articles Series: HOWTO: Create a toolwindow for the VBA editor of Office from an add-in with Visual Studio .NET.

The next article about creating an add-in for the VBA editor of Office with the .NET Framework, and before writing articles related to the setup, is about creating toolwindows. If you thought it was going to be easy…it’s tricky as hell, with several issues. But fortunately I have found workarounds for all of them:

HOWTO: Create a toolwindow for the VBA editor of Office from an add-in with Visual Studio .NET.
http://www.mztools.com/articles/2012/MZ2012017.aspx

The strange case of projects not being rebuilt

Yesterday while writing code for the next article about creating add-ins for the VBA editor of Office using Visual Studio .NET I noticed that when I used this approach to debug it, the add-in project was not being rebuilt when I changed some code and hit F5 to debug:

  • In the Solution Explorer of the Visual Studio project, right-click the solution
    node and click the “Add”, “Existing Project…” menu entry.
  • Select the path to Excel.exe, for example “C:\Program
    Files\Microsoft Office\Office14\EXCEL.EXE”.
  • Right-click the EXCEL.EXE node and click the “Set as Startup Project” menu
    entry.
  • Right-click the EXCEL.EXE node and click the Properties menu entry.
  • In the Debugger Type field, change its value from “Auto” to “Managed (v2.0)”.
  • Click the “Debug”, “Start Debugging” menu.
  • Excel will be launched.
  • Open the VBA editor and load the add-in. The breakpoint should be hit in the
    add-in project.

I remembered that the same happened to me some months ago with the solution of my add-in MZ-Tools 6.0, that contained the main add-in project and other projects for external operations of the MZ-Tools 6.0 SDK: the projects of the external operations were not rebuilt when I debugged the main add-in project.

The reason is that by default, the setting “Only build startup projects and dependencies on Run” that is in the “Tools, “Options…” window, “Projects and Solutions”, “Build and Run” section is checked. Once you uncheck it, the issue is solved.

I have updated the article that I wrote a couple of days ago to reflect this:

HOWTO: Debug an add-in for the VBA editor (32-bit or 64-bit) of Office with Visual Studio .NET.
http://www.mztools.com/articles/2012/MZ2012014.aspx

MZ-Tools Articles Series: HOWTO: Create a button with a custom picture for the VBA editor of Office from an add-in with Visual Studio .NET.

After explaining how to create buttons with a built-in Office picture using the CommandBarButton.FaceId property, the next step is to use custom pictures. Tricky as always for the conversion from .NET bitmap to OLE IPictureDisp, but at least fortunately the use of the clipboard (CommandBarButton.PasteFace) is no longer necessary as it was in initial versions of Microsoft Office and in VB5/VB6 add-ins.

HOWTO: Create a button with a custom picture for the VBA editor of Office from an add-in with Visual Studio .NET.
http://www.mztools.com/articles/2012/MZ2012016.aspx

MZ-Tools Articles Series: HOWTO: Adding buttons, commandbars and toolbars to the VBA editor of Office from an add-in with Visual Studio .NET.

Now that I already explained how to create a basic add-in for the VBA editor of Office using Visual Studio and the .NET Framework, and how to debug it, it’s time to add a more complex user interface:

HOWTO: Adding buttons, commandbars and toolbars to the VBA editor of Office from an add-in with Visual Studio .NET.
http://www.mztools.com/articles/2012/MZ2012015.aspx

MZ-Tools Articles Series: HOWTO: Debug an add-in for the VBA editor (32-bit or 64-bit) of Office with Visual Studio .NET.

A new installment of the series of articles that I am devoting to building add-ins for the VBA editor of Microsoft Office using the .NET Framework and Visual Studio, this time related to debugging:

HOWTO: Debug an add-in for the VBA editor (32-bit or 64-bit) of Office with Visual Studio .NET.
http://www.mztools.com/articles/2012/MZ2012014.aspx

While it may seem pretty straightforward, it is a bit tricky to set it right, specially if you are using Visual Studio 2010 (that can use two CLRs, 2.0 and 4.0) and you use the lower one (CLR 2.0). It happens that VS 2010 can have one behavior and VS 2010 with SP1 another one (resulting in debugging or not debugging at all). SP1 introduced this problem to Visual Studio add-ins too, and after I reported it to Microsoft through Microsoft Connect here, they released the hot fix http://support.microsoft.com/kb/2591546, which however “We do not recommend that you install this hotfix if you use Visual Studio to create Office add-in projects.“.

Fortunately the article shows three different procedures to debug Office add-ins that work around these problems.

MZ-Tools Articles Series: HOWTO: Get the current theme and detect changing it from a Visual Studio 2012 add-in.

I am currently adding support for the Dark / Light themes of Visual Studio 2012 in my MZ-Tools 7.0 add-in for Visual Studio, which is resulting much harder than expected because there are a lot of issues. I will blog about them in a future post when the work is done, but meantime I have written this sample to show how an add-in can know the current theme and how to get notified when the theme is changed:

HOWTO: Get the current theme and detect changing it from a Visual Studio 2012 add-in.
http://www.mztools.com/articles/2012/MZ2012012.aspx

One thing that may surprise you is that if you have opened several VS 2012 instances, changing the theme in one of them changes it in ALL of them. So, it is not enough for an add-in to know when the theme has been changed through the Tools, Options window of the instance where it is hosted. Visual Studio 2012 broadcasts a

WM_SYSCOLORCHANGE message
, so an add-in must intercept that message through some top-level window. While an add-in could do subclassing of the main IDE window, that’s an approach prone to crashes if two extensions do the same (because subclassing must be undone in reverse order), so my sample uses a dummy invisible top-level form.

The new Visual Studio 2012 IDE and SDK introduces new services and methods related to themes, for example the IVsShell5 interface of the Microsoft.VisualStudio.Shell.Interop.11.0.dll assembly, so maybe there is some other way to get notified when the theme changes (I don’t know), but my approach with MZ-Tools is to use a single binary add-in dll, so I can’t add as references assemblies that are not in VS 2005, as I explained in the article:

HOWTO: Create an add-in that targets several Visual Studio versions with the same add-in DLL using C# or VB.NET.
http://www.mztools.com/articles/2011/MZ2011012.aspx