Excel Programming : VBA

Using Custom Functions in Dynamic Ranges

Gabhan Berry — Tue, 19 Feb 2008 20:33:00 GMT

Named ranges are great. They enable us to assign a name to a collection of cells and use that name in code and worksheet functions. However, named ranges tend to be static. That is, they tend to represent a fixed set of cells, such as, A1:E100. But sometimes it would be useful to have the range's set of cells be dynamic. Instead of the range representing a fixed set of cells, we would like to dynamically determine which cells are included in the range based on some custom logic.

Excel already lets us do this. It allows us to embed functions inside the definition of a named range and have the functions determine on-the-fly which cells are included in the range. But it's not just native Excel functions (like IF, OFFSET, etc.) that we can embed into a named range defintion. We can also embed our own, custom functions; we can write a custom function that uses our own application logic to dynamically determine at calculation time which cells are in a named range.

This gives us the capability to point the named range at different cells without actually changing the named range's definition.

In this posting, I'll talk about dynamic ranges and embedding custom functions into named range defintions.

Getting Started with Dynamic Ranges

Let's take a simple example. Let's say that we have a column of numbers in the range 'Example 1'!$C$1:$C$100 and we want to find the cells in this range that are higher than some value, X = 34,999.

Using dynamic ranges, we can create a named range (called, say, Range 1) with a definition of:

=GreaterThan('Example 1'!$C$1:$C$100, 34999)

We also define a UDF called GreaterThan as:

Public Function GreaterThan(Rng As Range, Limit As Long) As Range
    Dim Cell As Range
    Dim ResultRange As Range

    For Each Cell In Rng
        If Cell.Value2 > Limit Then
            If ResultRange Is Nothing Then
                Set ResultRange = Cell
            Else
                Set ResultRange = Application.Union(ResultRange, Cell)
            End If
        End If
    Next
    Set GreaterThan = ResultRange
End Function

The UDF iterates over the source range testing each cell. If the cell meets our criteria (in this case its value being greater than 34999) then it is added into a temporary range object. Once the code has iterated over all the cells, the temporary range is returned to the caller. This range represents the set of cells the named range now refers to.

(Note: we're not coping with any runtime errors in this code ... which we should do in a proper version).

We can use the named range just like any other named range and Excel will call our UDF as and when it needs to. So, we could calculate the average of our range by using normal worksheet functions, such as:

=AVERAGE(Range1)

We can visually confirm the range that our UDF returned using the Name Manager. If we open up the Name Manager and select Range 1 and then click inside the 'Refers to:' textbox, Excel invokes our UDF and highlights the cells on the worksheet that our UDF returned.

Recalculating the Range when Data Changes

Excel knows that our dynamic range depends on $C$1:$C$100. This is because we pass $C$1:$C$100 to the UDF call in the named range definition.

This enables Excel to properly calculate our named range during worksheet calculations.

In our example, the cell $E$3 (which contains the formula =AVERAGE(Range1)) depends on Range 1 and Range 1 depends on $C$1:$C$100. Therefore, if $C$1:$C$100 changes, Excel knows that it needs to recalculate Range 1 in order to recalculate $E$3.

So, if we change the value of $C$1 from 40000 to 20000 Excel knows that it needs to recalculate $E$3 and, hence, invokes our UDF. Our UDF determines which cells Range 1 refers to and deems that $C$1 is no longer part of Range 1 (because its value is no longer > 34999); thus the value of $E$3 changes, as shown below.

We can also confirm that Range1 is comprised of different cells by inspecting Range1's address in the VBA Immediate window (this also illustrates that we can use the dynamic named range in VBA just like we can use a 'normal' named range).

A Note about Interacting with the Calc Tree

If our UDF didn't declare its source data range as a parameter then Excel would not be able to call it at the appropriate times during recalculation.

For example, if our UDF simply iterated through $C$1:$C$100 without declaring this range as a parameter then, when $C$1:$C$100 is changed, $E$3 wouldn't be recalculated.

This is because Excel would not know that $E$3 depends on $C$1:$C$100 because that dependency would be hidden inside the UDF.

There may circumstances when we don't care about this. But it is worth remembering that Excel needs to know about any worksheet dependencies our UDF has in order for our dynamic range to interact with the calculation tree properly.

Making More Use of Dynamic Ranges

Our GreaterThan UDF is about as basic as could be, but, it illustrates the technique. It doesn't, however, take much imagination to see how this technique could be used in more sophisticated ways.

For example, inside our UDF we could make use of external data, such as our company's databases, and use the logic and/or data stored in them to determine the contents of the dynamic range in Excel.

One example could be that we have a list of dates in our worksheet and we want to highlight the dates on which somebody downloaded a trial version of our product from our web site. This would make use of the same technique described here, except, in the loop in our UDF, we would make a call to the database to determine whether that cell should or should not be included in the range.

In other words, using UDFs in dynamic ranges enables us to incorporate external data and external components into our range definitions.

Another use is: search. We could write a fairly sophisticated custom, search feature that is built on top of dynamic ranges and UDFs.

Concerns About Execution Speed

I'm afraid I've left the bad news until the end...

Implementing dynamic ranges exactly as I have described here could hand you serious performance issues.

To illustrate this, let's change the definition of Range 1 from:

=GreaterThan('Example 1'!$C$1:$C$100, 34999)

to:

=GreaterThan('Example 1'!$C:$C, 34999).

Now, we are checking for cells greater than 34999 in the entire C column. In Excel 2007, that's 1,048,576 cells. On my PC (which is a 2.66 GHz dual core with 3GB RAM - not that dual core helps here anyway), calculating the range once takes 3 seconds. If we referenced Range 1 in only a handful of places in our workbook or VBA, our workbook would become fairly unusable fairly quickly.

It would be interesting to see if implementing our UDF in an XLL would improve the speed substantially - (something I'll look into).

Also, if our UDF did fancier things (like calling into an external database) then you can just imagine what would happen when we're iterating over 1,048,576 cells ....

So, it's worth stating that we should exercise some common sense and some judgement when using dynamic ranges. However, if we restrict our usage to suitably sized source ranges, dynamic ranges are a useful tool indeed (where suitably sized is something we each have to define for ourselves).

Summary

Named range definitions can contain native and custom functions;
A custom function used as a named range definition should return the range that it determines the named range represents;
To interact properly with Excel's calculation tree, all worksheet dependencies (such as the source range) should be included as parameters to the custom function;
Dynamic ranges can be used to build some fairly useful and sophisticated extensions;
Speed when iterating over large ranges is not good and we should employ careful judgment when using dynamic ranges on potentially large source ranges;

You can download the workbook I used for this post in the list of attachments below.

Creating Custom Calculated Members and Sets in OLAP PivotTables

Gabhan Berry — Wed, 06 Feb 2008 22:45:00 GMT

If you are using PivotTables against an OLAP data source you may find it useful to be able to create your own custom, calculated measures and sets. These calculations are client-side meaning they exist inside Excel and you don't have to change the server-side OLAP cube.

Excel does not enable you to do this using the user interface, however, you can do this via the API.

Allan Folting (our PivotTable expert) has published a post showing how to do this using VBA over in the team's blog.

Click here to read his post.

MSDN Code Gallery

Gabhan Berry — Tue, 05 Feb 2008 23:02:00 GMT

We have recently launched a code sharing community web site called MSDN Code Gallery.

MSDN Code Gallery hosts code snippets and entire projects that have been shared with the community. You can publish your own code or search for and download other peoples' code.

There are lots of nice features on the web site. For example, when you publish code, the site enables issue tracking, discussions, comments and RSS feeds pertaining to your release.

The basic format is that you create resource pages. These pages each have descriptions, versioning etc. and contain releases. Each release is a file. It can be a code snippet or documentation or any other useful file. You search the gallery using tags or using the embedded Live search. Also, the web site automatically enforces the Microsoft Public License on all the source code downloads.

All in all, it seems like a great idea, so, I'll be publishing all my source code to the MSDN Code Gallery.

If you're interested in publishing your own code, you can find out how to do it here.

As an example, the resource page for my post on filtering a PivotTable using cell contents has been published here. The workbook can be downloaded from the Releases tab.

Using Cell Text to Filter PivotTables

Gabhan Berry — Fri, 01 Feb 2008 02:50:00 GMT

Sometimes it would be useful to be able to use cells to select items in a PivotTable. For example, let's say we have a PivotTable containing a field called Region. Instead of using the filter dropdown to select the region from a list it would be nice if we could use a cell to specify the region. That way, the user could just type a region, such as Europe, into a cell and the PivotTable would only show data for Europe.

In this post, I'll present some VBA code that does just this.

Let's take an example.

We have a PivotTable based on some census data in our workbook. We have Occupation on rows and Education Level on columns and our measure is average age. So we are looking at the average ages of different occupations and education levels.

We then want to filter this data by region. So we add the Region field to report filters. Now we can see the different values for different regions by changing the in-built filter dropdown.

But let's say that, instead of using the filter dropdown, we want the PivotTable to get the region selection from a specific cell. In other words, we want the user to be able to type Europe into a cell and the PivotTable updates to show the value for Europe, just as if the user had used the filter dropdown to select Europe.

To do this, we need to do two things:

Detect when the user has entered a value into the cell;
Update the Region PivotField object with the value of the cell;

For the sake of clarity, let's assign a name to the cell where the user will enter the new selection for the field (i.e. let's make the cell a named range). Since we're changing the Region field, let's give the cell a name of RegionFilterRange.

To detect when RegionFilterRange has changed, we handle the Workbook.SheetChange event. This event passes in (as a parameter) a Range object which represents the changed range. If this range intersects with the RegionFilterRange then we know that RegionFilterRange has changed.

Private Sub Workbook_SheetChange(ByVal Sh As Object, ByVal Target As Range)
    If Not Intersect(Target, Application.Range(RegionRangeName)) _
        Is Nothing Then
            UpdatePivotFieldFromRange _
            RegionRangeName, PivotFieldName, PivotTableName
    End If
End Sub

PivotFieldName is the name of the the field we are updating (in this case Region) and PivotTableName is the name of the PivotTable we are changing.

The code for updating the PivotField object is implemented in the function UpdatePivotFieldFromRange. I've made the code generic so that it can update any field in any PivotTable (in the active workbook) to the value of a specified range (these three things are passed in as parameters).

Public Sub UpdatePivotFieldFromRange(RangeName As String, FieldName As String, _
PivotTableName As String)

    Dim rng As Range
    Set rng = Application.Range(RangeName)

    Dim pt As PivotTable
    Dim Sheet As Worksheet
    For Each Sheet In Application.ActiveWorkbook.Worksheets
        On Error Resume Next
        Set pt = Sheet.PivotTables(PivotTableName)
    Next
    If pt Is Nothing Then GoTo Ex
    On Error GoTo Ex

    pt.ManualUpdate = True
    Application.EnableEvents = False
    Application.ScreenUpdating = False

    Dim Field As PivotField
    Set Field = pt.PivotFields(FieldName)
    Field.ClearAllFilters
    Field.EnableItemSelection = False
    SelectPivotItem Field, rng.Text
    pt.RefreshTable

Ex:
    pt.ManualUpdate = False
    Application.EnableEvents = True
    Application.ScreenUpdating = True

End Sub

Public Sub SelectPivotItem(Field As PivotField, ItemName As String)
    Dim Item As PivotItem
    For Each Item In Field.PivotItems
        Item.Visible = (Item.Caption = ItemName)
    Next
End Sub

UpdatePivotFieldFromRange first of all gets a reference to the required PivotTable and stores it in pt. Then it gets a reference to the required PivotField and stores that in Field.

pt.ManualUpdate = True stops the PivotTable from automatically updating as we make changes. It basically means that we have to tell the PivotTable when it should update. Application.EnableEvents = False stops events like Workbook.SheetChange from firing while our code is executing.

SelectPivotItem loops through all the items in the field and sets each one's Visible property to False except for the item specified by ItemName which is set to True. This ensures that only ItemName will be visible in the field.

Notice that in UpdatePivotFieldFromRange we set Field.EnableItemSelection = False. This hides the dropdown filter window from the user so they can't click on the PivotTable and change the field selection using the filter dropdown list.

So, our code now enables us to enter an item name in the RegionFilterRange named range and use that value to filter our PivotTable.

It doesn't matter where the Region field is. It could be on Report Filters, Columns or Rows. In the following screenshot, we have moved Region to Columns.

Summary

Cells can be used to filter PivotTables by programmatically setting the field selection to the value of the cell;
Use the Workbook.SheetChange event to detect changes to the cell;
Set Application.EnableEvents = False and PivotTable.ManualUpdate = True to avoid Excel events from firing and the PivotTable automatically updating itself while your code exeutes;

I have only talked about PivotTables that are based on data inside Excel. This code won't work for OLAP PivotTables. I might post a OLAP version in a later article if there is interest.

Download the Source Code

An example Excel 2007 workbook containing the VBA, data and PivotTable for this post has been published to the MSDN Code Gallery and can be downloaded by clicking on the link below (go to the Releases tab to download the workbook).

Click here to download