Clean pastes with Excel VBA

dtjohnso — Fri, 14 Dec 2007 16:50:31 +0000

I’ve talked about some of the Excel VBA I’ve done before, and here’s a new thing I learned today.

Problem

One part of my application selects a range from one worksheet in the spreadsheet and pastes it onto another. Originally, the code I used looked like this:

destinationWorksheet.Range("A2").Select
ActiveSheet.Paste

There is one problem I was unaware of. Every time the .Paste operation executed, it added a new "Named Range" to the ActiveSheet. I only realized this when snooping around in the Properties for the Excel file, where I found (to much dismay) 840 different "Named Ranges" referring to data long since thrown away! An older version of my application, which used this unspecified Paste operation much more frequently, had even more of these attached to numbers of other worksheets.

Solution

The first thing I looked into was the properties of the .Paste method itself. Turns out there are two of them, "Destination" and "Link," and they are more or less mutually exclusive. The Excel VBA Help provides good explanation of that which I won't reproduce here. The reason my old call for an unparameterized .Paste worked was that it simply used the current selection as the "Destination" property. This is explained from this portion of the Help document:

Destination Optional Variant. ... If this argument is omitted, the current selection is used.

I had assumed that this parameter was irrelevant. The increase in these weird "Named Ranges" made me suspicious. I modified my .Paste call this way to see if it would make a difference:

ActiveSheet.Paste Destination:=ActiveCell

Adding a parameter that specifies the default parameter anyway isn't a pretty fix, would it work? After executing a few calls to the .Paste statement in question, I was shocked! It did make a difference! No more "Named Ranges" were being appended to the ActiveSheet.

Cleanup

Wonderful, now I had 840 "Named Ranges" stuck in my file for no reason, referring to data long since wiped off the sheet. Some quick Help file searching taught me some things.

Each Worksheet object in a Workbook contains a collection of Name objects called Names. The Name objects in this collection are the "Named Ranges" in question. With some quick 'n dirty coding, I wiped them all out. Solution is below:

Private Sub NameDR4ng3z()
    ThisWorkbook.Worksheets("destinationWorksheetName").Activate

    For Each myName In ActiveSheet.Names 'list '
        Debug.Print myName.Name
    Next myName

    For Each myName In ActiveSheet.Names 'delete '
        myName.Delete
    Next myName

    Debug.Print "Names deleted? We'll see"
    For Each myName In ActiveSheet.Names 'double-check '
        Debug.Print myName.Name
    Next myName
End Sub

This worked. I'm happy.

Fixing memory leaks in Excel VBA… (we hope)

dtjohnso — Fri, 14 Sep 2007 02:05:52 +0000

One project I constantly return to is an application I built in Excel VBA that does a lot of different things. One specific problem remains unsolved with this application, so I’ve decided to throw it out here and see if any gurus have an answer.

Basically, as a result of some Excel memory leaks beyond my control (I can’t install recommended hotfixes on the computers where this application is used, and need to be able to handle the issue with/without hotfixes anyway), when I shut down Excel it typically remains stuck in memory (and visible under “Processes” in “Task Manager”) even though it looks like it is gone to the user.

Paranoia

I realize that many would argue that since this bug is Microsoft’s problem and not mine, that I shouldn’t trouble with addressing it. However, since this application I’ve built is something that gets used frequently (but not constantly) throughout the day, I can imagine this becoming a problem (or at least wasting resources) at some point.

Another rejoinder to this charge is quite simple: I’ve actually ignored this issue for about a year now already, and am only revisiting it because I’ve learned some things about VBA that enable me to possibly defeat it. If I didn’t have any hope of fixing this, I wouldn’t try.

Problem (in more depth)

Here is what I know about why one of my memory leak problems exists (this article won’t deal with all my memory leak issues in the application, since I still haven’t made any headway on the others). I may not have quite the right diagnosis here, but tests to this point suggest I might be on the right track.

The main worksheet in my application includes numerous embedded control buttons that marshall up various cool features I’ve built for this VBA app. Unfortunately, it appears that embedding any sort of control (as far as I can tell) on a worksheet can cause Excel to commit memory leaks.

Before going further, a few notes about the KB article I just mentioned:

This article refers to an issue with Excel 97.
I’m not sure that worksheet buttons are considered ActiveX or OCX controls

The problem here is simple: I did some research on this a year ago when I first discovered the issue, and didn’t keep track of the KB article I found that suggested the problem with embedded buttons. I remember reading something like that then, but can’t find it now. The only reason I think this might actually be the source of the problem is because my hacked solution seems to prevent the memory leak in question.

Ugly solution

I learned that it is possible in Excel VBA to write an Auto_Close sub to override default behavior when closing a spreadsheet. ~~(If I ever track down the documentation that tipped me off to this, I’ll link to it here.)~~

This suggested that I might be able to do something on the file’s close event that might at least catch and destroy the source of the memory leak before the Excel app slipped out of my control until an inevitable Ctrl+Alt+Del. Here’s the ugly, scary code:

Sub Auto_Close()
    'Deletes the spreadsheet with the embedded buttons '
    Application.DisplayAlerts = False
    ThisWorkbook.Worksheets("Sheet1").Delete

    'Prevents prompt to save changes, so that workbook closes without saving '
    'This prevents the sheet from being really deleted '
    ThisWorkbook.Saved = True
End Sub

Concerns

After this function fires, Excel closes as normal, without saving the file. Since this fires whenever the user closes the file, it seems safe enough to do this, but you can’t help being a little bit frightened with an approach like this.

Tests and reasoning

I think this works. Before, when I would exit Excel, an instance of EXCEL.EXE would remain in my “Process” list in Task Manager until I manually terminated it, logged out, or rebooted. Now when I exit Excel, it disappears from the list as normal (unless I’ve used some other parts of the application which induce the other memory leak problems I’m not discussing here). It appears that the embedded button memory leak problem is bypassed (I really hesitate to say “solved”).

Suggestions?

If you have handled this problem before, have more information, or know how a better (and saner) way to fix this, please post a comment!

output stream » VBA