I have an Excel 2007 VBA project which works fine on my computer and some others, but on some it hits error 32809 on a line that references the ActiveSheet object. I found that on the affected computers, the ActiveSheet object is not recognized. The ActiveWorkbook object works fine.
On the affected computers, if I create a new workbook, reference ActiveSheet, and activate the affected workbook, the ActiveSheet object works normally; I can get the Name property of ActiveSheet.
On my computer the VBA compiles fine. But on the affected computers, Compile stops on an "Option Explicit" line and returns the error:
"Contains references to object definitions that could not be found." But the selected entries in the References dialog look normal.
On the affected computers we've checked for updates but they were up to date; I assume IT handles updates remotely.
My thoughts are that:
The strange behavior suggests workbook corruption, but the fact that it works fine on some computers suggests not. All the computers are on Excel 2007 SP3.
On the other hand, the fact that it works fine on some computers but not on others, suggests a problem with Excel on the affected computers.
Any ideas?
UPDATE:
Sample code, as requested:
Sub main()
Debug.Print ActiveSheet.Name
End Sub
UPDATE #2:
Thinking it might be workbook corruption, I rebuilt the workbook from scratch. But the new workbook had the same problem.
On a computer where the error was happening, I saved a copy of the file as xlsx, no macros. Then I closed and opened that file to ensure that the macros were gone. Then I copied back all VBA from the original file. Then I resaved as xlsm, with macros.
That file worked fine on the affected computer, and also worked fine on the original computer.
However, on the original computer, if I saved the file, then copied that to the affected computer, it was back to the original problem.
So that gives me a clumsy workaround anyway. Next I'll try KB article 3025036, "Cannot insert object" error after installing MS14-082 security update. Not the same error message but worth a try.
could you post the code please?
Also one thing to check for is that you are not trying to put the Excel.ActiveSheet Object into a Worksheet Object without verifying it's Type. The Activesheet can also be a Chart Object (i.e. a Chart Sheet).
Sub Example()
Dim ws As Excel.Worksheet
'Risks Error:
Set ws = Excel.ActiveSheet
'Safer:
If TypeOf Excel.ActiveSheet Is Excel.Worksheet Then
Set ws = Excel.ActiveSheet
Else
'Do something else:)
End If
End Sub
To check against corruption, copy/paste everything into a new workbook, export your code module and re-import them into the new workbook, then compile. If that fixes it, then it likely was corruption.
This problem went away only after removing all listbox controls. The listbox controls had been there a long time and had been working fine on the affected machines; I'm not sure what suddenly changed to make them not work on some computers.
As a workaround, I'm going to try deleting/creating the listboxes in runtime, instead of using the same listbox control. That way it's always a new listbox created on that computer.
UPDATE:
It turned out that the problem was a bad Office update -- update KB2596927 from the MS14-082 security update. We hadn't had a problem back in November when that update came out, but recently our corporate IT had tried removing KB2596927 from all computers. However, the removal was not successful on some. KB2596927 was still there on mine and some others, but gone from some.
I found that if, on a computer where the problem occurred, I removed the VBA and added it back, it worked on that comptuter and all our computers. But as soon as I modified the VBA on my computer and saved it, and distributed the workbook, the problem was back.
So I removed the KB2596927 Office update, and that fixed the problem. Now I can modify the VBA in the workbook on my computer, and distribute the workbook, and it works normally for everyone.
I had same issue. The VBA compiler shows a problem in line:
ActiveSheet.Shapes("Key_1").Visible = False
and it didn't reorganized the function (and the shape also).
I solved this issue very simple!
I made a copy from same sheet (price list_2018) to "price list_2018 (2)
then I deleted the sheet "price list_2018" and then
I renamed "price list_2018 (2)" to "price list_2018" ... very easy!
The issue has been gone!
Thank You ...
Related
I have been creating a .xlsm Workbook that contains various bits of VBA. It simply copies data from two other workbooks into tables and then refreshes the PivotTables that are based on those tables to update the charts on the main workbook. All things I have done before in different workbooks without issue. Whilst working on the workbook I have naturally open, saved, and then closed the workbook several time over several different days.
Typically, now that I believe the workbook to be finished, it has developed a glitch whilst opening. Initially I was unable to open the file at all, as it would immediately crash. Only by saving the file to onedrive and downloading it back again, have I been able to keep the file open to see what is going on (for some reason this worked, I don't know why!).
I immediately suspected something in the VBA and so one press of Alt+F11 later I was confronted with this (image above).
All of the Blue Excel Objects in this picture were not created by me!
They contain no code and I do not seem to be able to open them as regular Excel Worksheets.
My Questions are,
does anyone have any idea what may be causing this?
Has anyone even seen this before?
Where do I start debugging this?
Attempting to run any of the VBA in the workbook causes it to instantly crash.
The VBA i suspect the most for the crashing is in these sections;
Public Function ThisWorkbookPath()
ThisWorkbookPath = ThisWorkbook.Path & Application.PathSeparator
End Function
which is passed to;
Public Function CheckPath(ByVal PathString As String) As Boolean
Application.Volatile (True)
If Strings.Right(PathString, 1) = "\" Then
CheckType = vbDirectory
Else
CheckType = vbNormal
End If
If Len(Dir(PathString, CheckType)) > 0 Then
CheckPath = True
Else
CheckPath = False
End If
End Function
These are both used in the workbook as user defined functions to check if the folder that contains the other 2 workbooks exists on the computer before trying to open them.
ThisWorkbook is now ThisWorkbook1 which might explain why, as the forumla in the workbook calculates, it can't find the correct path and just crashes.
But this doesn't explain where these extra objects came from in the first place.
Any help would be gratefully appreciated
I just had the same issue with Office365, made a code review and found out that I was using the same name for a public constant and a parameter to a function. After renaming the parameter and rerunning the macro, it did not happen again.
I have a strange problem, I suscpect it's connected to the version of the Excel, but I'm not sure at all. I can't figure it out alone so I need your help. I have a macro, which operates on a fresh workbook - it's not saved anywhere, as the worker will save it manually afterwards. The macro is a .xlam format add-in, adding a couple of buttons to the ribbon and these buttons start the code.
Inside the code I have simple lines for opening a new workbook, chosen earlier by an user:
Application.DisplayAlerts = False
Set wbMPA = Workbooks.Open(MPA_file)
Application.DisplayAlerts = True
Earlier, the code sets active workbook as an object/workbook the macro will mainly work on (tried both versions):
Set dwb = Application.ActiveWorkbook
and later in the code
dwb.activate
OR:
dwb = ActiveWorkbook.Name
and then
workbooks(dwb).Activate
The lines are in separate subs, but the variable is globally declared.
The code works fine until the opening of wbMPA (watching it in the locals all the time). When I try to open the new file with the code above, the earlier workbook (dwb) just closes itself from unknown reasons.
The error I get from the 1st method is this:
error screenshot
The second one gives a simple "Subscipt out of range".
The errors, however, are not a problem. The problem is the cause of them, which is closing of the workbook from unknown reasons.
It happens only when I open the completely new workbook (using the excel icon on the Start bar) - when I do it from File -> New -> Blank Workbook using already opened workbook, the error does not occur.
Another strange thing - me and my colleague from work use 2013 version of Excel. I never have this error, she has it every time.
This is a general scheme of the code, other things are meaningless in this case because there are no other manipulations of workbooks/worksheets.
Dim dwb As Object
Dim wbMPA As Object
Sub_1()
Set dwb = ActiveWorkbook
Set wbMPA = Workbooks.Open(MPA_file)
Call Sub_2
End Sub
Sub_2()
dwb.Activate
End Sub
I get an error on the activation of dwb in Sub_2, because it closes itself for God knows what the reason on the opening of wbMPA in the Sub_1.
If you have only opened a blank workbook (clicking Excel from Toolbar, for example) and then you open any named workbook before making any changes to the blank workbook, the blank workbook will disappear. I believe that is normal/expected behavior.
I can't speculate why this happens on one computer but not another, but this is always how I have observed new/blank documents (Excel, PowerPoint, Word) to behave, and assume this to be the normal behavior. You may have some different option/configuration on your Excel environment which is changing this default behavior, or maybe you are slightly altering the blank file before running the macro, and your co-worker isn't, etc.
A word of caution to avoid relying on ActiveWorkbook -- and especially in this case if the expectation is to always Set dwb to a new/blank workbook, the best way to do that is to explicitly create a new/blank workbook, rather than relying on the user to manually open a new/blank target workbook.
Set dwb = Workbooks.Add
If, on the other hand dwb must be assigned to some other known/existing workbook, then you should be either providing the file path to an Open statement, or the workbook name to the Workbooks collection.
On a related note, it's almost never necessary to Activate a workbook, see here:
How to avoid using Select in Excel VBA macros
And further note: your variables aren't globally scoped, they're scoped only to the module using Dim statement. A public declaration uses the Public keyword, not the Dim keyword. Both module-scoped and global-scoped should be used with caution (Public moreso than module-scoped) and in most cases it's preferable to pass objects/variables by reference to dependent subs and functions:
How to make Excel VBA variables available to multiple macros?
I have this strange problem. I have a vba project, where the project explorer displays more than one workbook object. It is exactly the same as in this SO question, but I don't have any faulty references to uncheck.
However, I do know what's caused it and I'm sure you can all duplicate. What I did was use the codename for a sheet as a byref argument for a simple sub and at the end of the sub, nulled the worksheet object. So I nulled the whole sheet through the reference.
Something like:
Option Explicit
Sub test_1()
test_2 sh:=Sheet2
End Sub
Sub test_2(ByRef sh As Worksheet)
Set sh = Nothing
End Sub
If you run test_1, it will run without problems. But after that, the 'Sheet2' codename is invalid. And if you close and reopen the workbook, you'll see what I mean. Excel creates a new worksheet with the same name (but another CodeName). Any data stored in the cells of the sheet is not lost. The old CodeName references the Workbook Object.
I have not found a way to restore or remove the old references so far (other then move all the objects to a new workbook). I am using Excel 2013.
Solution is of course not so null the worksheet, but does anyone have any idea how to restore?
Well, after suffering this weird behaviour of Excel I can finally say that I have tried man times and that I can confirm that the cause (at least for my experiments) was indeed using User Defined Functions (UDFs). There is no way of fixing a Workbook once the extrange sheets appear. My approach was to just create a new Workbook and copy all the Modules and all the sheets from the old (broken) one.
Just make sure to not use user defined functions if you are having this issue.
All,
I just upgraded to Excel 2013 and am running into a strange issue. I have a macro-enabled workbook that has worked successfully for quite some time now. I was updating some of the code and came across this error (32809) when trying to write to a specific sheet. In troubleshooting, I tried this.
Sheets("Summary").Range("G8").Value = "Test"
This resulted in the same error. Then I tried this.
Debug.Print ActiveSheet.Name
Same error. So I selected another sheet on the workbook and debug.print on the name. Worked fine.
Then I tried this.
Debug.Print Sheets(2).Name (This is the sheet number of the problemic sheet)
Same error. It seems to me that there is some form of corruption with this sheet but I am reticent about deleting and recreating. Any suggestions?
Thanks!
While it wasn't a perfect solution, here is how I finally resolved it. I had a user that was still on Excel 2010 make a copy the corrupt sheet within the same workbook, delete the corrupt sheet, then rename the new sheet to the original name. I was then able to use the workbook in Excel 2013 without issue.
I have a Workbook Open Macro which counts the number of rows in a table on opening so that I can summarize how many records were added or deleted during the data entry session:
Private Sub Workbook_Open()
Dim TotalRows As Integer
TotalRows = Worksheets("Data").ListObjects(1).ListRows.Count
If Range("LastRecordOnStart") <> TotalRows Then Range("LastRecordOnStart") = TotalRows
' Stop
End Sub
I started getting the run-time error '32809' with the following line in the code above highlighted in the debugger every time I opened the workbook...
TotalRows = Worksheets("Data").ListObjects(1).ListRows.Count
Rebooting or opening the workbook on another PC still would not fix it. Even opening a previously saved working copy would give the same error - strange. Note:
While coding, I will periodically save the workbook and use windows explorer to copy a snapshot of the workbook where it creates myworkbook copy(1).xlsm, copy(2).xlsm, etc and if I get a corrupted workbook, I rename it myworkbook.bad.xlsm and rename the latest saved working version (e.g myworkbook copy(6).xlsm to MyWorkbook.xlsm with minimal loss.
When this run-time error occurs though, I've had to rebuild the book several times. It only appears to happen when the workbook crashes after a long session of debugging new code with the Userform open and I have to close excel from the Task Manager.
I read the posts here today and was convinced that it was page related when I could list the listrows count on another sheet and if I converted the Listobject on the "Data" worksheet back to a range and recreated the table, I'd still get the run-time error. To cut a long story short, I tried the following:
Open the workbook
When the error popped up, clicked debug
Right clicked on the "End Sub" line of the WorkBook_Open sub and clicked "Set Next statement"
Pressed F5 to allow the code to finish executing
Saved the workbook and it all works now!
I had another crash with the subsequent run-time error and repeated the steps above and it worked a charm again.
I have a private subroutine in Workbook A that is running any time I open or close and save other unrelated workbooks. I'm trying to understand why that occurs so I can capture all potential errors that may occur.
The subroutine is an ActiveX ComboBox named TabProg that is supposed to run when the value is changed. I have currently added in a check to see if the active sheet trying to run the code is the "Program Loading" sheet to try and divert any potential errors. See snippet below.
Private Sub TabProg_Change()
MsgBox "Whomp!", vbOKOnly + vbExclamation
If ActiveSheet.Name <> "Program Loading" Then 'do nothing
Else
'Run desired actions on "Program Loading" sheet
End If
End Sub
Any known reasons why this is occurring or other ways to catch it would be helpful. Thanks!
Edit 1: I do not see this problem occur when I open other workbooks in new instances of Excel.
Edit 2: I have modified the code to include a message box whenever the code tries to run, now shown above. It is occurring every time I open or close and save any Excel file, including the file itself. The drop down list in the ActiveX ComboBox is a list of names that correspond to 10 sheets within Workbook A. If I delete the sheet that ComboBox is currently set to, the error will disappear. If I change the ComboBox to a different sheet, the error will reappear.
From what you've wrote in your question, I don't think that your problem can be replicated. I think that your Excel file got corrupted. I had an experience like this: had a file for experimenting with macros, one of the macros used Excel Speech object to say "This is a test file" on opening that particular file. The macro was (as all other macros from this file) not part of my PERSONAL workbook, it was assigned to ThisWorkbook in the bespoke file. At some point a funny thing happened: this "This is a test file" private subroutine got activated every time I opened any Excel file. I did not find any solutions, I just deleted the file where the subroutine was stored. This resolved the problem, but I have no explanation for this. I am afraid the same thing may apply to your file, but maybe other folks have a better idea... maybe it's something in the system registry??? I don't know. Can you manually copy elements / code from this file to a newly created file and just delete the original?