MZ-Tools Articles Series: BUG: CommandBar.Name property localized in VBA editor of Office.

Visual Studio causes problems to developers of add-ins in localized versions (as I blogged four years ago), but it is not the only one. The automation model of the VBA editor of Microsoft Office has also problems in localized versions. The CommandBar class has the Name and NameLocal properties for the English name and the localized name, but there are commandbars with its Name property localized (non-English) and others with its NameLocal property not localized (English). This poses a challenge to add-ins for the VBA editor when trying to get a commandbar by its (English) name:

BUG: CommandBar.Name property localized in VBA editor of Office.
http://www.mztools.com/articles/2012/MZ2012020.aspx

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.

VS SDK, packages, add-ins, macros and more…