This and other RefEdit problems skyrocketed as users of my commercial utilities upgraded to Excel 2007 and beyond, to the point where I had to find an Alternative to Excel’s Flaky RefEdit Control. When I converted RefEdits to this alternative technique, support calls decreased by at least 90%. This was a nice change, but I didn’t think that the alternative worked as smoothly as a working RefEdit.

Alternative Approach

I was mulling over this issue with RefEdits recently, especially the fact that it seemed worse when the dialog was designed using one version of Excel and deployed on another version. Then I realized that if the problem is a mismatch between the RefEdit library on my machine and the library on a user’s machine, I should let the user’s machine add the RefEdits to the dialog.

This is accomplished with a teeny bit of VBA code:

    Set ctl = Me.Controls.Add("RefEdit.Ctrl", RefName, True)

where Me refers back to the form, RefEdit.Ctrl is the class name for a RefEdit control, ctl is a variable declared as an Object, RefName is a string variable containing the name of the RefEdit control, and True reflects the visibility of the control.

With this in mind, I designed a dialog with space for two RefEdits; the user will select two ranges, one which will be filled in with red, the other with blue. The dialog has a label for each RefEdit, a button to clear any fill colors in the worksheet, and an OK button to apply the red and blue fills and to dismiss the dialog.

On the worksheet is a simple Forms Menu button that runs the following code to load the dialog:

Sub RefEditOnTheFly()
  Load UserForm1
  UserForm1.Show
End Sub

The dialog contains the following code in its module:

Private Sub UserForm_Initialize()
  Dim ctl As Object
  Dim i As Long

  For i = 1 To 2
    ' add RefEdit control
    Set ctl = Me.Controls.Add("RefEdit.Ctrl", "RefEdit" & i, True)

    ' position and size RefEdit control
    With Me.Controls("RefEdit" & i)
      .Top = Me.Controls("Label" & i).Top + 12
      .Left = 27
      .Height = 15.75
      .Width = 264
      .TabIndex = Me.Controls("Label" & i).TabIndex + 1
    End With
  Next
End Sub

Private Sub btnClear_Click()
  ' remove fill color from worksheet
  ActiveSheet.Cells.Interior.ColorIndex = xlNone
End Sub

Private Sub btnOK_Click()
  On Error Resume Next
  ' apply fill color to selected ranges
  Range(Me.Controls("RefEdit1").Text).Interior.Color = RGB(255, 0, 0)
  Range(Me.Controls("RefEdit2").Text).Interior.Color = RGB(0, 0, 255)
  Unload Me
End Sub

UserForm_Initialize runs when the form first loads, and adds the two RefEdit controls. btnClear_Click and btnOK_Click run when the buttons are clicked and remove or apply fill colors.

Here is how the dialog looks when it first loads:

When the user clicks in a RefEdit and starts to select a range, the dialog is compressed to the size of the RefEdit, and the selected range is highlighted with the “marching ants” border.

Here the dialog has had both RefEdits populated with ranges from the worksheet. The RefEdit containing the blue range has focus (note the cursor at the end of the address) so the ants are marching around this range.

When the dialog is dismissed with the OK button, the red range is filled in, then the blue range is filled in. The blue fill color fills any red cells from the red range.

Try It, You’ll Like It

I’ve put together a small Excel 2003 workbook to test out this RefEdit scheme. It has a simple worksheet, blank except for the “Go” button that loads the dialog. The dialog contains the two RefEdits shown above, drawn using VBA when the Go button is clicked.

If you’re willing to try it out, download the RefEdit-on-the-fly.zip zip file, unzip the RefEdit-on-the-fly.xls Excel workbook inside it, and open the workbook. Then add a comment below, telling me the version of Excel you’re using, including Service Pack number, and if you’re using Excel 2010, whether you’re using the 32- or 64-bit version. Also mention any language pack, if you are not using English. Then tell me whether the dialog with RefEdits behaves as shown above. If the dialog fails, let me know what error messages you receive (the whole message, not just the number).

Peltier Technical Services, Inc., Copyright © 2011.
 
Licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.
 

Now you have to update the chart to show year to date information, but you don’t want to generate all new charts. You also would rather not go through the hassle of copying data and pasting it into each chart, or worse, navigate the source data dialog umpteen times.

Here’s your old pal Jon with a time saving VBA routine to update your charts painlessly.

Last Year’s Report

In your acclaimed report, you compared 2008 and 2009 monthly sales. Very nice, the generally increasing trend seen in 2008 continued in 2009. Must be a fine product.

The data for this chart is in a simple table, shown below with the source data highlighted by selecting the chart.

The Interim Report

In the intervening months, sales data for 2010 has been generated, in the next column of the table. Now we have to add this data to the chart.

All that is needed is to select the chart and run the VBA procedure below. The code starts with the series formula of the last series in the chart:

=SERIES(Report!$C$1,Report!$A$2:$A$13,Report!$C$2:$C$13,2)

which contains the series source data as follows:

=SERIES(Name,X_Values,Y_Values,Plot_Order)

The code extracts the Y_Values argument, then depending on the orientation of this data, determines the next column or row of data to use for the Y values of a new series.

If the name of the existing last series was taken from the worksheet, then the corresponding cell in the next column or row will provide the name for the new series; otherwise, the generic name “Series N” will be used. The new series will use the same X values as the existing last series.

The code adds a new series with the old X values, the new Y values and series name, and a plot order one higher than the last:

=SERIES(Report!$D$1,Report!$A$2:$A$13,Report!$D$2:$D$13,3)

Here is the resulting chart:

Awesome, monthly sales have followed the upward trend. When we select the chart, we can easily see that the source data now includes the range for the new series.

The code is listed below. It’s not too complicated, and includes a little bit of error handling in case you forgot to select a chart before running it, or in case the series formula of the last series cannot be parsed into something useful.

It’s common courtesy to give the user a meaningful explanation of why your code crapped out (or why they broke it):

The alternative is ugly.

Sub AddSeriesToEnd()
  ' Add series to active chart
  ' Use same X values
  ' Use Name and Y values one column to right of last existing series
  Dim sFmla As String
  Dim iParen As Long
  Dim sFmlaArgs As String
  Dim vFmlaArgs As Variant
  Dim sMsg As String
  Dim iOffset As Long
  Dim jOffset As Long
  Dim rValues As Range
  Dim rName As Range

  If ActiveChart Is Nothing Then
    sMsg = "Select a chart, and try again."
    GoTo CantHandle
  End If

  With ActiveChart
    sFmla = .SeriesCollection(.SeriesCollection.Count).Formula
    iParen = InStr(sFmla, "(")
    sFmlaArgs = Mid$(sFmla, iParen + 1)
    sFmlaArgs = Left$(sFmlaArgs, Len(sFmlaArgs) - 1)
    vFmlaArgs = Split(sFmlaArgs, ",")

    If UBound(vFmlaArgs) + 1 - LBound(vFmlaArgs) <> 4 Then
      sMsg = "Series Formula too complicated to parse"
      GoTo CantHandle
    End If

    On Error Resume Next
    Set rValues = Range(vFmlaArgs(2))
    Set rName = Range(vFmlaArgs(0))
    On Error GoTo 0

    If rValues Is Nothing Then
      sMsg = "Last series values are not in a range"
      GoTo CantHandle
    End If

    If rValues.Rows.Count > 1 And rValues.Columns.Count = 1 Then
      ' series in columns, so offset 1 column
      jOffset = 1
    ElseIf rValues.Rows.Count > 1 And rValues.Columns.Count = 1 Then
      ' series in rows, so offset 1 row
      iOffset = 1
    Else
      ' one cell or multiple rows and columns
      sMsg = "Series values range cannot be parsed"
      GoTo CantHandle
    End If

    vFmlaArgs(3) = vFmlaArgs(3) + 1
    If Not rName Is Nothing Then
      vFmlaArgs(0) = rName.Offset(iOffset, jOffset).Address(True, True, xlA1, True)
    Else
      vFmlaArgs(0) = "New Series " & vFmlaArgs(3)
    End If
    vFmlaArgs(2) = rValues.Offset(iOffset, jOffset).Address(True, True, xlA1, True)

    sFmlaArgs = Join(vFmlaArgs, ",")
    sFmla = Left$(sFmla, iParen) & sFmlaArgs & ")"
    With .SeriesCollection.NewSeries
      .Formula = sFmla
    End With
  End With

ExitSub:
  Exit Sub

CantHandle:
  ' display generated error message
  MsgBox sMsg, vbCritical + vbOKOnly
  GoTo ExitSub
End Sub

If you’re not sure how to make use of this code, please read How To Use Someone Else’s Macro.

Peltier Technical Services, Inc., Copyright © 2011.
 
Licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.
 

The utility does not apply any particular formatting to the output charts, using the defaults it finds. One user of the utility had charts with over 100 series, and he wanted them all to be formatted identically.

In Excel 2003 and earlier, this is easy to do manually. Format the first series as desired, select the next series (use the up arrow key), press the F4 key, repeat the up arrow/F4 cycle until all series look the same. However, in Excel 2007, the F4 (Repeat Last Action) functionality has been eviscerated, particularly in charts. This is one of the productivity-sapping changes I have discussed in the past.

I wrote a little VBA procedure to apply the same formatting to all series in the chart. I wrote the routine in Excel 2003, but it will work fine in Excel 2007. It does not make use of the more extensive formatting capabilities introduced in Excel 2007, and that is just as well, since they do nothing to enhance the effectiveness of a chart.

Sub FormatAllSeriesTheSame()
  Dim srs As Series

  For Each srs In ActiveChart.SeriesCollection
    srs.MarkerStyle = xlMarkerStyleNone
    With srs.Border
        .ColorIndex = 5 ' blue lines
        .Weight = xlThin
        .LineStyle = xlContinuous
    End With
  Next
End Sub

Select the chart and run the code.

We can improve on this routine, making it a better experience for the user. First, the following routine can check that there is an active chart. If not, the code exits gracefully with a reminder that the user should select a chart first. Second, to avoid the screen flashing and to speed up the reformatting, the routine deactivates ScreenUpdating while it is reformatting the chart.

Sub FormatAllSeriesTheSame()
  Dim srs As Series

  If ActiveChart Is Nothing Then
    MsgBox "Select a chart and try again.", _
        vbExclamation + vbOKOnly, "No Active Chart"
  Else
    Application.ScreenUpdating = False
    For Each srs In ActiveChart.SeriesCollection
      srs.MarkerStyle = xlMarkerStyleNone
      With srs.Border
        .ColorIndex = 5  ' blue
        .Weight = xlThin
        .LineStyle = xlContinuous
      End With
    Next
    Application.ScreenUpdating = True
  End If
End Sub

If you aren’t sure how to use this code, please read my tutorial about How To Use Someone Else’s Macro.

Peltier Technical Services, Inc., Copyright © 2011.
 
Licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.
 

These controls are prone to incompatibility issues between versions of Excel, particularly between Classic Excel (up to 2003) and new Excel (2007 and later), and whenever there’s a new security update from Office update, these problems seem to arise again. I’ve written about this and related problems in Unspecified but Painfully Frustrating Error. This error has led to an inordinate amount of customer support to update customer installations and correct the errors.

To improve the user experience of my customers, and to cut down on customer support incidents, I’ve replaced the RefEdit controls in all of my commercial utilities with an alternative method, as I’ve discussed in Charting Utility Upgrades. This article describes the replacement for the RefEdit functionality.

RefEdit

A typical dialog using a RefEdit looks like this:

Clicking in the RefEdit highlights the indicated range. The user can edit the text within the RefEdit, and the highlighted range updates.

Clicking in the RefEdit’s drop box, or selecting a range in the sheet contracts the dialog so that only the refEdit is visible, and the indicated range updates as the user changes the selection.

TextBox and Inputbox

The new approach uses a TextBox in the dialog instead of the RefEdit, which at first doesn’t look like it’s going to work:

We can use a couple invisible properties of a TextBox to provide a drop button like that in the RefEdit, so it looks exactly the same in the dialog. I call the properties “hidden” because they do not appear in the TextBox property window in the VB Editor, though they appear for example in the ComboBox property window. Fortunately you can type the properties and they work. One hidden property is TextBox.DropButtonStyle which sets the style of the drop button (see below); we use the “Reduce” style to match the RefEdit. The other property is TextBox.ShowDropButtonWhen which controls the visibility of the drop button, and we write code that always shows the drop button.

The TextBox does not interact directly with a range as does the RefEdit. Instead, when this drop button is clicked, the dialog is temporarily hidden, and an InputBox appears to solicit the user’s input.

The InputBox control is familiar to Excel VBA programmers who use it to ask the user to enter a number or some text. The syntax of the InputBox is:

Application.InputBox(Prompt, Title, Default, Left, Top, HelpFile, HelpContextId, Type)

Prompt is the text that instructs the user, Title is the text in the title bar of the dialog, Default is the value in the input box when the InputBox opens. Left and Top define the position of the InputBox (if unspecified it appears in the center of the window). HelpFile and HelpContextId are used with custom help topics. Finally, Type is used to define the expected type of input:

It may be tempting to use type 8 to indicate a range object, but there is an obscure glitch that causes it to fail when the worksheet contains conditional formatting conditions that use formulas in their definitions. Fortunately using Type 0 to specify a formula works just fine.

The dialog with the drop-button-enabled TextBox looks like this:

By itself the drop button has no function, but we can write code to respond to the user clicking on it. We have the dialog hide itself and show the following InputBox:

The InputBox is larger than the compact dialog that shows only the active RefEdit, but that’s a minor cosmetic difference. The largest drawback of this approach is that it doesn’t show the highlighted range when the user is editing the text in the TextBox. The advantage of course is the avoidance of incompatibilities between RefEdit and the user’s MS Office environment.

The Code

The following procedure, in a regular code module, determines the address of the selected range, loads the dialog, passes the range address to the dialog, and waits for the user to finish. If the user does not cancel the dialog, then the procedure selects the new range.

Sub ShowDialog()
  Dim frmAlternativeRefEdit As FAlternativeRefEdit
  Dim rRange As Range
  Dim sRange As String
  Dim bCanceled As Boolean

  If ActiveSheet Is Nothing Then Exit Sub

  If TypeName(Selection) = "Range" Then
    Set rRange = Selection.Areas(1)
    sRange = Selection.Parent.Name
    If InStr(rRange.Address(, , , True), "'") > 0 Then
      sRange = "'" & sRange & "'"
    End If
    sRange = sRange & "!"
    sRange = sRange & rRange.Address
  End If

  Set frmAlternativeRefEdit = New FAlternativeRefEdit
  With frmAlternativeRefEdit

    .Address = sRange
    .Show

    ' wait for user input

    bCanceled = .Cancel
    If Not bCanceled Then
      sRange = .Address
    End If
  End With

  Unload frmAlternativeRefEdit
  Set frmAlternativeRefEdit = Nothing

  If bCanceled Then GoTo ExitSub

  If IsRange(sRange) Then
    Application.Goto Range(sRange)
  End If

ExitSub:

End Sub

The UserForm (dialog) is named FAlternativeRefEdit. The following code all goes into the code module behind the UserForm.

At the top of the code module we need:

Option Explicit
Private mbCancel As Boolean

When the dialog is initialized, the drop button style and visibility are set:

Private Sub UserForm_Initialize()
  Me.txtRefChtData.DropButtonStyle = fmDropButtonStyleReduce
  Me.txtRefChtData.ShowDropButtonWhen = fmShowDropButtonWhenAlways
End Sub

We include this snippet to make sure closing the dialog using the big red X is the same as pressing the Cancel button:

Private Sub UserForm_QueryClose(Cancel As Integer, CloseMode As Integer)
  If CloseMode = vbFormControlMenu Then
    Cancel = True
    btnCancel_Click
  End If
End Sub

The Cancel and OK buttons run the following code:

Private Sub btnCancel_Click()
  mbCancel = True
  Me.Hide
End Sub

Private Sub btnOK_Click()
  mbCancel = False
  Me.Hide
End Sub

The dialog gets the address from the calling procedure and passes back the new address using these properties:

Public Property Let Address(sAddress As String)
  CheckAddress sAddress
End Property

Public Property Get Address() As String
  Dim sAddress As String

  sAddress = Me.txtRefChtData.Text
  If IsRange(sAddress) Then
    Address = sAddress
  Else
    sAddress = Application.ConvertFormula(sAddress, xlR1C1, xlA1)
    If IsRange(sAddress) Then
      Address = sAddress
    End If
  End If

End Property

Public Property Get Cancel() As Boolean
  Cancel = mbCancel
End Property

When the user clicks the DropButton on the TextBox, this code runs:

Private Sub txtRefChtData_DropButtonClick()
  Dim var As Variant
  Dim rng As Range
  Dim sFullAddress As String
  Dim sAddress As String

  Me.Hide

  On Error Resume Next
  var = Application.InputBox("Select the range containing your data", _
      "Select Chart Data", Me.txtRefChtData.Text, Me.Left + 2, _
       Me.Top - 86, , , 0)
  On Error GoTo 0

  If TypeName(var) = "String" Then
    CheckAddress CStr(var)
  End If

  Me.Show
End Sub

Me.Left + 2 and Me.Top - 86 are empirically derived positioning values that align the InputBox to the dialog that called it. They were not rigorously determined and may not work the same for all settings in all versions of Windows.

Finally, this procedure parses the address in the InputBox, making sure the format (xlA1 or xlR1C1) is appropriate, and also ensuring that the user can select a range on a different worksheet. I’ve incorporated the suggestion made by Julien in the comments, who found that my original CheckAddress routine gave the wrong address if an entire column or row was selected.

Private Sub CheckAddress(sAddress As String)
  Dim rng As Range
  Dim sFullAddress As String

  If Left$(sAddress, 1) = "=" Then sAddress = Mid$(sAddress, 2, 256)
  If Left$(sAddress, 1) = Chr(34) Then sAddress = Mid$(sAddress, 2, 255)
  If Right$(sAddress, 1) = Chr(34) Then sAddress = Left$(sAddress, Len(sAddress) - 1)

  On Error Resume Next
  sAddress = Application.ConvertFormula(sAddress, xlR1C1, xlA1)

  If IsRange(sAddress) Then
    Set rng = Range(sAddress)
  End If

  If Not rng Is Nothing Then
    sFullAddress = rng.Address(, , Application.ReferenceStyle, True)
    If Left$(sFullAddress, 1) = "'" Then
      sAddress = "'"
    Else
      sAddress = ""
    End If
    sAddress = sAddress & Mid$(sFullAddress, InStr(sFullAddress, "]") + 1)

    rng.Parent.Activate

    Me.txtRefChtData.Text = sAddress
  End If

End Sub

Sample Workbook

RefEdit_Alternative.zip is a zipped workbook that contains the dialog and code featured in this post. Click on the button on the first worksheet to see it in action.

Summary

Using a TextBox and InputBox is an effective replacement for Excel’s RefEdit control.It may not be quite as elegant as the RefEdit, when the RefEdit is working. However, the TextBox/InputBox combination does not suffer from incompatibilities between different systems and Excel versions. Since I have converted my professional utilities to this alternative system, my customer support incidents have been reduced by 90%.

Peltier Technical Services, Inc., Copyright © 2011.
 
Licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.
 

Microsoft Office User Interfaces

Microsoft introduced a flexible and powerful user interface system in Office 97, and this interface has remained in use through Office 2003 (and a subset remains in use in later versions). The user interface consists of various command bars, which include menu bars and toolbars. Command bars can contain menus as well as buttons. Menus can contain submenus and buttons. Submenus can contain, well, you get the idea. This system of menus, toolbars, and buttons is easily customized through the user interface and via VBA.

Here is what our add-in’s menu customizations look like. This article shows how to create these customizations.

The Microsoft Office development team at Microsoft noticed some things about the command-bar-style interface, and about how users interacted with it. The interface was becoming complicated, with three or more levels of menus and submenus existing in some places. Each application ended up with its Tools menu, a kitchen junk drawer of commands that didn’t logically fit into the other menus. Users didn’t know what all the features were, or couldn’t find them, if they were buried more than a level deep, so they kept suggesting new features which already existed. Many users also didn’t know how to clean up their interfaces, so there were too many rows of docked toolbars and too many floating toolbars obstructing the workspace.

In response to the complicated nature of the command-bar-based interface and to the inability of some users to learn to use it as intended, the Microsoft Office team gutted the interface, replacing most toolbar implementations in favor of a new Ribbon in Office 2007. The ribbon is controlled using XML instead of VBA. Instead of toolbars which are visible all or most of the time, the ribbon has a set of different tabs. These tabs contain fewer buttons, and the buttons used more tend to be larger. The tabs become visible when the Office program thinks you might want to use them, and invisible when you actually do want to use them. No parts of the new interface can be undocked, so users who didn’t know how to click the close box of a floating toolbar now have clean interfaces, while users who like dispatching toolbars and palettes to areas on the screen where they are needed have to resort to extra mouse travel distances and excess mouse clicks. The ribbon-based interface is easy to customize using the RibbonX XML dialect and related VBA callbacks, but it is practically inaccessable through the user interface. Unless, of course, you count the QAT (Quick Access Toolbar), which is like a Classic toolbar on strong sedatives. Fortunately the ability of a user to customize their own interface was resuscitated for use in Office 2010.

This article will show how to construct a simple set of Classic Excel menu and toolbar customizations using VBA. The next article in the sequence will show simple XML code and VBA callbacks for use in New Excel.

Classic Excel User Interface Code

The object model for the Office command bar system is straightforward. The CommandBars collection contains menu bars, standard toolbars, and popup menus (context or right-click menus). There is a lot of documentation of this system on the internet. This article shows a set of simple, hard-coded routines, all that is necessary for this simple add-in. There are a number of examples of more elaborate and flexible routines that use tables in Excel workbooks to define all of the interface elements to be created. John Walkenbach describes Creating Custom Menus using his MenuMakr system. I started with his system, but like any good engineer, I tweaked it beyond all recognition to create the system I use in my own add-ins and in projects for my clients.

Here is the simple code in its entirety, copied out of its code module. Explanations for selected sections of the code follow the complete listing.

''========================================================================
'' Peltier Technical Services, Inc., Copyright © 2010. All rights reserved.
''========================================================================
Option Explicit

Const sMenuName As String = "&PTS Charts"
Const sToolbars As String = "Worksheet Menu Bar|Chart Menu Bar|PTS Charts"
Const sButton As String = "PT_Plotter"
Const sOnAction As String = "PT_Plotter_Dialog"

Sub Create_PTPlotter_Menu()
  Dim ctlpop As CommandBarPopup
  Dim ctlbtn As CommandBarButton
  Dim iMenu As Long
  Dim vMenu As Variant

  Delete_PTPlotter_Menu

  vMenu = Split(sToolbars, "|")

  For iMenu = LBound(vMenu) To UBound(vMenu)
    On Error Resume Next
    If Application.CommandBars(vMenu(iMenu)) Is Nothing Then
      With Application.CommandBars.Add(vMenu(iMenu), msoBarFloating)
        .Left = Application.Left + Application.Width / 4
        .Top = Application.Top + 144
        .Visible = True
      End With
    End If
    On Error GoTo 0

    With Application.CommandBars(vMenu(iMenu))
      On Error Resume Next
      If .Type = msoBarTypeMenuBar Then
        Set ctlpop = .Controls(sMenuName)
        On Error GoTo 0
        If ctlpop Is Nothing Then
          Set ctlpop = .Controls.Add(10, 1, , , True)
          With ctlpop
            .Caption = sMenuName
            .Visible = True
          End With
        End If
        Set ctlbtn = ctlpop.Controls.Add(1, 1, , , True)
      Else
        Set ctlbtn = .Controls.Add(1, 1, , , True)
        .Visible = True
      End If

      With ctlbtn
        .Caption = sButton
        .OnAction = "'" & ThisWorkbook.Name & "'!" & sOnAction
        .TooltipText = "Create chart from arbitrary data range"
        .FaceId = 422
        .Visible = True
      End With
      Set ctlpop = Nothing
    End With
  Next
End Sub

Sub Delete_PTPlotter_Menu()
  Dim ctlpop As CommandBarPopup
  Dim ctlbtn As CommandBarControl
  Dim iMenu As Long
  Dim vMenu As Variant

  On Error Resume Next
  vMenu = Split(sToolbars, "|")

  For iMenu = LBound(vMenu) To UBound(vMenu)
    With Application.CommandBars(vMenu(iMenu))
      If .Type = msoBarTypeMenuBar Then
        Set ctlpop = .Controls(sMenuName)
        Do
          Set ctlbtn = ctlpop.Controls(sButton)
          If ctlbtn Is Nothing Then Exit Do
          ctlbtn.Delete
          Set ctlbtn = Nothing
        Loop

        If ctlpop.Controls.Count = 0 Then
          ctlpop.Delete
        End If
      Else
        Do
          Set ctlbtn = .Controls(sButton)
          If ctlbtn Is Nothing Then Exit Do
          ctlbtn.Delete
          Set ctlbtn = Nothing
        Loop

        If .Controls.Count = 0 Then
          .Delete
        End If

      End If
    End With
  Next

End Sub

Explanations

The module starts by defining a few constants. The menu name sMenuName, “&PTS Charts” has an ampersand that tells Excel to use the next character (P) as an accelerator key, that is, to activate the menu when Alt plus the next character is pressed (Alt+P). This character will appear underlined in the menu name: “PTS Charts”.

sToolBars is a pipe-delimited string of command bars which will be customized. The remaining constants list the button caption and the name of the procedure to be run when the button is clicked.

Create_PTPlotter_Menu is the routine that adds our buttons to the Classic Excel interface. The first command in this routine is Delete_PTPlotter_Menu, which removes any existing buttons from this add-in which have somehow been orphaned due to a disorderly shutdown.

The pipe-delimited string is converted into an array of command bar names. The program loops through this array, looking for command bars with each name. If such a command bar is not found, then a new standard command bar is created using that name, other wise the program continues with the found command bar.

If the command bar is a menu bar, the program looks for a menu with the indicated name. If such a menu is not found on the command bar, a new menu is created, otherwise the existing menu is used. Then the button is placed on the menu. If the command bar is a regular toolbar, the button is placed directly on the toolbar.

The caption of the button is assigned, as is the name of the procedure to run when the button is clicked. The procedure name is prepended with the workbook name in single quotes, so Excel will not confuse our procedure with a procedure with the same name in another workbook.

The button is assigned its tooltip text, which appears when the cursor passes over the button.

Built-in button image number 422 is used for the button’s icon. Display FaceIDs is a simple utility that helps you browse Excel’s button images. Not described here is the means to assign a custom button image.

Finally the button is made visible, so users can find it.

Delete_PTPlotter_Menu goes through the command bars listed in the pipe-delimited string, looking for buttons with the name used by our add-in. This is done inside Do loops, in case multiple crashes left behind multiple identical buttons. If the last button of a menu or toolbar is deleted, the empty menu or toolbar is also deleted.

Our Menu and Toolbar

The menu and toolbar customizations produced by the code above are displayed below.

The menu is on the Worksheet Menu Bar; the menu on the Chart menu Bar is the same. The PTS Charts menu and the PTS Charts toolbar already existed, with a variety of my utilities displayed, and the PT_Plotter button is added at the end of the list.

Contents: How to Build an Excel Add-In

• Build an Excel Add-In 1 – Basic Routine
• Build an Excel Add-In 2 – Enhanced Functionality
• Build an Excel Add-In 3 – Auxiliary Modular Functions
• Build an Excel Add-In 4 – Create the Dialog
• Build an Excel Add-In 5 – Tie the Code Together
• Build an Excel Add-In 6 – Interface for 2003
• Build an Excel Add-In 7 – Interface for 2007
• Build an Excel Add-In 8 – Last Steps
• Build an Excel Add-In 9 – Deployment

Create_LblLastPt_Menu

Peltier Technical Services, Inc., Copyright © 2011.
 
Licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.
 

When you run the macro to make your chart the next time, you get no chart. Instead you get an ugly error message.

That’s frustrating. All you did was record and rerun a macro. You didn’t even change the code, so at least this once, you couldn’t have messed it up. And still it crashed.

Let’s examine the macro recorder code.

Sub RecordedMacro_MakeBubbleChart()
'
' RecordedMacro_MakeBubbleChart Macro
' Macro recorded 1/26/2010 by Jon Peltier
'

'
    Charts.Add
    ActiveChart.ChartType = xlBubble
    ActiveChart.SetSourceData Source:=Sheets("Sheet1").Range("A1:C7"), _
        PlotBy:=xlColumns
    ActiveChart.Location Where:=xlLocationAsObject, Name:="Sheet1"
End Sub

The macro recorder follow the order of the Excel 2003 chart wizard, putting the chart type before the chart source data. The steps given by the recorder work fine for most chart types, but a few chart types cannot be correctly assigned until the chart has been populated with sufficient data. In particular, code which creates stock charts and bubble charts will fail if you set the chart type before the chart is populated with data.

To make the code run properly without crashing, all you need to do is switch the SetSourceData and ChartType commands. The following code works fine.

Sub RecordedMacro_MakeBubbleChart()
'
' RecordedMacro_MakeBubbleChart Macro
' Macro recorded 1/26/2010 by Jon Peltier
'

'
    Charts.Add
    ActiveChart.SetSourceData Source:=Sheets("Sheet1").Range("A1:C7"), _
        PlotBy:=xlColumns
    ActiveChart.ChartType = xlBubble
    ActiveChart.Location Where:=xlLocationAsObject, Name:="Sheet1"
End Sub

This code isn’t particularly efficient, but at least it works. You can improve it following the suggestions in How To Fix a Recorded Macro.

This error has existed in Excel from the first modern version (Excel 97) through Excel 2003. Microsoft must have received inquiries about the problem, and they addressed it with a KB article, How to Use a Visual Basic Macro to Create a Bubble Chart., which propagated through versions 5/95, 97, 2000, 2002, and 2003. The author of the article didn’t think to rearrange the two VBA commands, so he wrote a long procedure that made an XY chart, and for markers, the chart used custom AutoShape circles sized according to the bubble values. It’s a nice procedure and a nice technique to know, but also a long voyage to go such a short distance.

When Microsoft rebuilt the charting infrastructure for Excel 2007, they changed some of the code produced by the macro recorder. Here is the Excel 2007 bubble chart macro:

Sub RecordedMacro_MakeBubbleChart()
'
' RecordedMacro_MakeBubbleChart Macro
' Macro recorded 1/26/2010 by Jon Peltier
'

'
  ActiveSheet.Shapes.AddChart.Select
  ActiveChart.SetSourceData Source:=Range("'Sheet1'!$A$1:$C$5")
  ActiveChart.ChartType = xlBubble
End Sub

Excel 2007′s macro recorder has been criticized because it didn’t capture any actions that affected the new shapes which comprise the chart. But in the simple macro above, we see that some improvements were made to Excel 2007′s macro recorder:

• In earlier versions of Excel, a separate chart sheet is made, then later inserted in the worksheet. In 2007, a chart is directly added to the worksheet’s Shapes collection. That’s more efficient.
• More important, the chart type is not set until after the chart is populated with data. The error in recorded macros no longer occurs.

Peltier Technical Services, Inc., Copyright © 2011.
 
Licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.