Debugging asynchronous add-ins

Components

Asynchronous add-ins are delivered as a pair of files:

1. An XLL add-in, written in C++, and linked to XLLPUSH.LIB.
2. An XLA add-in, written in Visual Basic for Applications, based on one of the supplied template files. The XLA provides essential services, including a menu, dialogs and "wiring" code that manages the timing of the conversations between the add-in and Excel.

The XLA contains code that will automatically load the XLL, if it is not already loaded. This code uses the XLL_PATH string declared in modCommands to search for an instance of the XLL. If you want to control which version of the XLL is loaded (Release or Debug), you have two approaches available:

• Open the XLL before the XLA.
• Alter the XLL_PATH string in modCommands.

Initialising the XLA

The update mechanism depends on correct initialization. This includes the following steps:

• Create an instance of the COM object XlpAsync.PushHandler.
• A successful call to PushHandler.Init().
• Connect event handlers for the events raised by the PushHandler object.

All this initialization is carried out by the method OnOpen() in the code module for ThisWorkbook.

Every time you change code in any module, the variables held in memory by Excel's VBA engine are thrown away and become invalid. This will include the instance of PushHandler that is managing the communications between Excel and the asynchronous XLL's push engine.

So, every time you change some code, you should run the Sub OnOpen() in order to reinitialize the connections between Excel, the XLA and the XLL. The add-in will not start updating until you do. You can do this most easily by placing the cursor somewhere in the body of OnOpen() and pressing the F5 key.

Debugging through C++

You can debug your C++ code as usual, and invoke the Visual Basic debugger within Excel.

This can lead to some irritating UI behaviour, since the VB and C++ debuggers use different short-cut keys for just about every important operation. You will probably find that you eventually get used to it, but it can be very confusing.

Remember that if your XLL crashes for any reason, or if you stop the C++ debugger, you will lose all unsaved changes to your spreadsheets and XLA. So, in Excel, save often and early.

Debugging without DevStudio

If you are just making changes to your XLA, and the XLL is stable, you prefer to edit and debug in Excel without using the C++ debugger.

Remember that the XLL_PATH string in modCommands controls which XLL is loaded by the XLA. You may want to change the path to, for example, "Release", while you are at this stage of development.

Next: Distributing asynchronous add-ins >>