I have developed an Excel file that contains a button with a macro that will save the workbook for the user. This has worked well until recently when we are migrating to Sharepoint and users are trying to save the workbook to a mapped drive that is mapped to a Sharepoint location.
So, for example, my user has \\<server#SSL\sites\<sitename>\<documentlibrary> mapped to her Z drive.
When I use ThisWorkbook.GetSaveAsFilename the result returns a url like so https://<server#SSL\sites\<sitename>\<documentlibrary>\<filename>.xlsm
Before making any changes, I was getting a run-time error on the line
ThisWorkbook.SaveAs Filename:=excelFile
where excelFile is https://<server#SSL\sites\<sitename>\<documentlibrary>\<filename>.xlsm
My first attempt was to do some find/replace on the string. First replacing https: with nothing and then replacing the forward slash / with the backslash \ to make it resemble a file path like so:
\\<server#SSL\sites\<sitename>\<documentlibrary>\filename.xlsm
There was some progress made here. I received no VBA error, however I did get a message:
UPLOAD FAILED We're sorry this didn't work. Try saving again later
and if that still doesn't work, click Save a Copy
and I see the file attempting to be uploaded in the Microsoft Office Upload Center, so this is progress.
I can't seem to make it around this upload failure message.
I have tested that my permissions to the document library are sufficient by manually uploading the file that I am attempting to automatically upload.
So, how can I use ThisWorkbook.SaveAs to save a file to a Sharepoint document library?
I am using Excel 2013 and Sharepoint 2013.
While I cannot explain it, after some tinkering around, I believe I have found the solution.
Changing
ThisWorkbook.SaveAs Filename:=excelFile
To
ThisWorkbook.SaveAs fileName:=excelName, FileFormat:=xlOpenXMLWorkbook, ConflictResolution:=xlUserResolution
Seemed to make it work.
I explicitly set the FileFormat and ConflictResolution arguments and the user is able to save.
Related
Background: I can't seem to find an answer for the blunder I've found myself in. I'm working on a dashboard of sorts for our organization that pulls data from different workbooks in different locations. Different people have different permissions within folders in our company. We're trying to prevent having to change permissions. I was also trying to make it easy as possible for employees by moving the necessary supporting files I pull from to my folder where the dashboard is housed that includes a folder with the supporting files. Since this folder has no restricted access, I added passwords to the whole workbook of each supporting file. I created workbooks in the original locations of where these supporting files used to reside with the hopes that would hopefully allow anyone with access in that folder to use this new file as a backdoor/shortcut of sorts. The goal was to keep people's files where they wanted them and allow them to click it then it takes them to my support file and enter the password for them. Which leads me to the problem...
Problem: When I open the "backdoor" file, everything runs normally and the support file opens up with read and write privileges. However when someone else opens the backdoor file, the support file opens as read only. While I don't have any code yet to determine if someone is in the file (I'll cross that road if my problem is resolvable), I've ensured nobody was in the support or backdoor file when another user attempted to use it.
Sub Workbook_Open()
'I didn't have the next statement orginally. Added it in hopes it'd resolve the issue.
'Tried to move it under the workbooks.open command, too, but to no avail.
SetAttr "M:\Report Writing\Supporting Files\TMR 2017 - Team ABC's SF.xlsm", vbNormal
Workbooks.Open "M:\Report Writing\Supporting Files\TMR 2017 - Team ABC's SF.xlsm", , False, , "XXX"
Workbooks("TMR 2017 - Team ABC's.xlsm").Close
End Sub
I also didn't originally have the "False" in the open.workbooks command but tried to add it in hopes of resolving my dilemma. Any hope is GREATLY appreciated as my whole dashboard is relying on this and we were supposed to deploy today.
It has nothing to do with the VBA code. It is the file itself. On a shared network, depending on how it was set up, when a new file is created everyone can read it, but only the creator is marked as the only one allowed to make changes. If someone Saves the file with another name you wont be able to edit it. You created the file, you can make changes to it.
There is a way to change this. Right click on the file, properties, security, Edit Button, There are some listed users in there but just find the one that says Drive\Users or Authenticated Users, or both, and edit that to provide modify access. This will allow everyone to edit the file.
I have VBA code that spins through a worksheet and creates workbooks that are emailed to clients. It's pretty simple, really, it writes the output files to My Documents. Here is the save code:
With wkbOutputBook
.CheckCompatibility = False
.Save
.Close
End With
When the worksbook is opened, Excel says:
PROTECTED VIEW Office has detected a problem with this file. Editing it may harm your computer. Click for more details.
OK I know what this means, for reasons unknown Excel thinks this file was sent through Outlook, or downloaded from the Internet. But it wasn't. I've tried the following:
Save in different versions/file formats
Use Save As instead of Save
Explicitly turn off protected mode. Protected mode isn't the same thing as Protected View though.
Surely "My Documents" isn't considered an "unsafe" location.
Thanks.
If you can accept files being saved in read only mode, this should probably eliminate an error message.
Dim path As String
path = "full-path-with-filename-and-extension"
With wkbOutputBook
.SaveCopyAs (path)
SetAttr (path), vbReadOnly
.Close
End With
You try .SaveCopyAs (path) method without code line involving setting read only, but I guess it won't help.
What format do you try to save your file as? Does the problem appear only on your PC or have You tested your macro / output files on other PCs? The problem can involve stuff in system registry.
I have an .xlsx file that when run through the open Office SDK 2.5 generates an error that the document is invalid and contains multiple validation errors involving the slicerCache and invalid attribute values.
I can attach more information about the actual XML if needed from the xlsx file, however my question is actually this. Excel still opens the document without an error. Not even a request to "repair" the document.
I am curious why using the Microsoft open office XML SDK generates validation errors, yet office is still able to open these documents.
Does office make a best guess? Or is the SDK given by microsoft not entirely accurate??
Thanks.
This is a formatting issue as far as I can tell. When you save it in xlsx it saves it as a workbook, not a spreadsheet. I would save it in a different file format or see if there libraries that your sdk needs in order to process the xlsx. I've never worked with office sdk, but I get similar errors when I open xlsx in other programs. 99% of the time I can just change the format. (if you live dangerously you can just manual change the file extension in your folder to something itll read.)
I have some Excel worksheets that use ActiveX checkboxes to control certain activity. They worked recently but today started to give errors. I was alerted to this by a colleague, but it was still working on my computer. I checked his version of Excel against mine and his was newer. I noticed there were new Windows updates, so I did the update. After I applied pending updates, it now no longer works on my computer. I cannot check the ActiveX checkboxes any longer, and, as a part of trying to debug, it appears I cannot even add an ActiveX control to any worksheet, even a new worksheet, any more. I get an error dialog that says, "Cannot insert object." (I can still add form controls, just not ActiveX.) Anyone else experiencing this after a recent update? Any suggestions?
Thanks,
Mike
From other forums, I have learned that it is due to the MS Update and that a good fix is to simply delete the file MSForms.exd from any Temp subfolder in the user's profile. For instance:
C:\Users\[user.name]\AppData\Local\Temp\Excel8.0\MSForms.exd
C:\Users\[user.name]\AppData\Local\Temp\VBE\MSForms.exd
C:\Users\[user.name]\AppData\Local\Temp\Word8.0\MSForms.exd
Of course the application (Excel, Word...) must be closed in order to delete this file.
Here is the best answer that I have found on the Microsoft Excel Support Team Blog
For some users, Forms Controls (FM20.dll) are no longer working as
expected after installing December 2014 updates. Issues are
experienced at times such as when they open files with existing VBA
projects using forms controls, try to insert a forms control in to a
new worksheet or run third party software that may use these
components.
You may received errors such as:
"Cannot insert object" "Object library invalid or contains references
to object definitions that could not be found"
Additionally, you may be unable to use or change properties of an
ActiveX control on a worksheet or receive an error when trying to
refer to an ActiveX control as a member of a worksheet via code.
Steps to follow after the update:
To resolve this issue, you must delete the cached versions of the
control type libraries (extender files) on the client computer. To do
this, you must search your hard disk for files that have the ".exd"
file name extension and delete all the .exd files that you find. These
.exd files will be re-created automatically when you use the new
controls the next time that you use VBA. These extender files will be
under the user's profile and may also be in other locations, such as
the following:
%appdata%\Microsoft\forms
%temp%\Excel8.0
%temp%\VBE
Scripting solution:
Because this problem may affect more than one machine, it is also
possible to create a scripting solution to delete the EXD files and
run the script as part of the logon process using a policy. The script
you would need should contain the following lines and would need to be
run for each USER as the .exd files are USER specific.
del %temp%\vbe\*.exd
del %temp%\excel8.0\*.exd
del %appdata%\microsoft\forms\*.exd
del %appdata%\microsoft\local\*.exd
del %appdata%\Roaming\microsoft\forms\*.exd
del %temp%\word8.0\*.exd
del %temp%\PPT11.0\*.exd
Additional step:
If the steps above do not resolve your issue, another step that can be
tested (see warning below):
On a fully updated machine and after removing the .exd files, open the file in Excel with edit permissions.
Open Visual Basic for Applications > modify the project by adding a comment or edit of some kind to any code module > Debug > Compile
VBAProject.
Save and reopen the file. Test for resolution. If resolved, provide this updated project to additional users.
Warning: If this step resolves your issue, be aware that after deploying this updated project to the other users, these users will
also need to have the updates applied on their systems and .exd files
removed as well.
If this does not resolve your issue, it may be a different issue and
further troubleshooting may be necessary.
Microsoft is currently working on this issue. Watch the blog for
updates.
Source
It was KB2553154. Microsoft needs to release a fix. As a developer of Excel applications we can't go to all our clients computers and delete files off them. We are getting blamed for something Microsoft caused.
I'm an Excel developer, and I definitely felt the pain when this happened. Fortunately, I was able to find a workaround by renaming the MSForms.exd files in VBA even when Excel is running, which also can fix the issue. Excel developers who need to distribute their spreadsheets can add the following VBA code to their spreadsheets to make them immune to the MS update.
Place this code in any module.
Public Sub RenameMSFormsFiles()
Const tempFileName As String = "MSForms - Copy.exd"
Const msFormsFileName As String = "MSForms.exd"
On Error Resume Next
'Try to rename the C:\Users\[user.name]\AppData\Local\Temp\Excel8.0\MSForms.exd file
RenameFile Environ("TEMP") & "\Excel8.0\" & msFormsFileName, Environ("TEMP") & "\Excel8.0\" & tempFileName
'Try to rename the C:\Users\[user.name]\AppData\Local\Temp\VBE\MSForms.exd file
RenameFile Environ("TEMP") & "\VBE\" & msFormsFileName, Environ("TEMP") & "\VBE\" & tempFileName
End Sub
Private Sub RenameFile(fromFilePath As String, toFilePath As String)
If CheckFileExist(fromFilePath) Then
DeleteFile toFilePath
Name fromFilePath As toFilePath
End If
End Sub
Private Function CheckFileExist(path As String) As Boolean
CheckFileExist = (Dir(path) <> "")
End Function
Private Sub DeleteFile(path As String)
If CheckFileExist(path) Then
SetAttr path, vbNormal
Kill path
End If
End Sub
The RenameMSFormsFiles subroutine tries to rename the MSForms.exd files in the C:\Users\[user.name]\AppData\Local\Temp\Excel8.0\ and C:\Users\[user.name]\AppData\Local\Temp\VBE\ folders to MSForms - Copy.exd.
Then call the RenameMSFormsFiles subroutine at the very beginning of the Workbook_Open event.
Private Sub Workbook_Open()
RenameMSFormsFiles
End Sub
The spreadsheet will try to rename the MSForms.exd files when it opens. Obviously, this is not a perfect fix:
The affected user will still experience the ActiveX control errors when running the VBA code the very first time opening the spreadsheet. Only after executing the VBA code once and restarting Excel, the issue is fixed. Normally when a user encounters a broken spreadsheet, the knee-jerk reaction is to close Excel and try to open the spreadsheet again. :)
The MSForms.exd files are renamed every time the spreadsheet opens, even when there's no issue with the MSForms.exd files. But the spreadsheet will work just fine.
At least for now, Excel developers can continue to distribute their work with this workaround until Microsoft releases a fix.
I've posted this solution here.
With Windows 8.1 I couldn't find any .exd files using windows search. On the other hand, a cmd command dir *.exd /S found the one file on my system.
Advice in KB and above didn't work for me. I discovered that if one Excel 2007 user (with or without the security update; not sure of exact circumstances that cause this) saves the file, the original error returns.
I discovered that the fastest way to repair the file again is to delete all the VBA code. Save. Then replace the VBA code (copy/paste). Save. Before attempting this, I delete the .EXD files first, because otherwise I get an error on open.
In my case, I cannot upgrade/update all users of my Excel file in various locations. Since the problem comes back after some users save the Excel file, I am going to have to replace the ActiveX control with something else.
The best source of information and updates on this issue I could find is in the TechNet Blogs » The Microsoft Excel Support Team Blog (as mentioned):
Form Controls stop working after December 2014 Updates (Updated March 10, 2015)
On March 2015 a hotfix was released in addition to the automated fix-it and manual instructions, and it's available on Windows Update as well.
The latest update and fix from Microsoft:
3025036 "Cannot insert object" error in an ActiveX custom Office solution after you install the MS14-082 security update
STATUS: Update March 10, 2015:
Hotfixes for this issue have been released in the March 2015 Updates for Office 2007, 2010 & 2013.
General info about the problem:
For some users, Form Controls (FM20.dll) are no longer working as expected after installing MS14-082 Microsoft Office Security Updates for December 2014. Issues are experienced at times such as when they open files with existing VBA projects using forms controls, try to insert a forms control in to a new worksheet or run third party software that may use these components.
https://technet.microsoft.com/en-us/library/security/ms14-082.aspx
You may receive errors such as:
"Cannot insert object"; "Object library invalid or contains references to object definitions that could not be found"; "The program used to create this object is Forms. That program is either not installed on your computer or it is not responding. To edit this object, install Forms or ensure that any dialog boxes in Forms are closed." [...]
Additionally, you may be unable to use or change properties of an ActiveX control on a worksheet or receive an error when trying to refer to an ActiveX control as a member of a worksheet via code.
Manual and additional solutions:
Scripting solution:
Because this problem may affect more than one machine, it is also possible to create a scripting solution to delete the EXD files and run the script as part of the logon process using a policy. The script you would need should contain the following lines and would need to be run for each USER as the .exd files are USER specific.
del %temp%\vbe\*.exd
del %temp%\excel8.0\*.exd
del %appdata%\microsoft\forms\*.exd
del %appdata%\microsoft\local\*.exd
del %temp%\word8.0\*.exd
del %temp%\PPT11.0\*.exd
Additional step:
If the steps above do not resolve your issue, another step that can be tested (see warning below):
On a fully updated machine and after removing the .exd files, open the file in Excel with edit permissions.
Open Visual Basic for Applications > modify the project by adding a comment or edit of some kind to any code module > Debug > Compile VBAProject.
Save and reopen the file. Test for resolution.
If resolved, provide this updated project to additional users.
Warning: If this step resolves your issue, be aware that after deploying this updated project to the other users, these users will also need to have the updates applied on their systems and .exd files removed as well.
Simplified instructions for end-users. Feel free to copy/paste the following.
Here’s how to fix the problem when it comes up:
Close all your Office programs and files.
Open Windows Explorer and type %TEMP% into the address bar, then press Enter. This will take you into the system temporary folder.
Locate and delete the following folders: Excel8.0, VBE, Word8.0
Now try to use your file again, it shouldn't have any problems.
You might need to wait until the problem occurs in order for this fix to work. Applying it prematurely (before the Windows Update gets installed on your system) won't help.
I did finally find this answer on the official Microsoft KB:
http://support.microsoft.com/kb/3025036/EN-US
No new information here than what we have in previous answers, but at least it acknowledges that Microsoft is aware of the issue.
I know many answers have already been posted for this, but neither one answer independently worked for my site. So here is what worked for me:
Step 1: Uninstall the following updates - KB2920789, KB2920790, KB2920792, KB2920793, KB2984942, KB2596927
Step 2: Hide these updates so they do not get installed on subsequent reboots
Step 3: Delete folder Excel8.0 from C:\Users\<>\AppData\Local\Temp
Step 4: Restart workstatiion (I would also make sure the above mentioned KBs did not inadvertently get applied)
I want to provide an answer that worked as the only thing for me (I realize that I might be the only one ever). I had in one macro that I was calling using the ribbon. It had the following code:
colStore = new Collection
I wasn't aware that it throws an error so I was baffled and tried everything in here. The button just stopped working and I couldn't get it to work. When I noticed the error and corrected it to:
Set colStore = new Collection
It started working again. Absolutely strange if you ask me but maybe it helps someone out there who was as desperate as me.
I have some Excel worksheets that use ActiveX checkboxes to control certain activity. They worked recently but today started to give errors. I was alerted to this by a colleague, but it was still working on my computer. I checked his version of Excel against mine and his was newer. I noticed there were new Windows updates, so I did the update. After I applied pending updates, it now no longer works on my computer. I cannot check the ActiveX checkboxes any longer, and, as a part of trying to debug, it appears I cannot even add an ActiveX control to any worksheet, even a new worksheet, any more. I get an error dialog that says, "Cannot insert object." (I can still add form controls, just not ActiveX.) Anyone else experiencing this after a recent update? Any suggestions?
Thanks,
Mike
From other forums, I have learned that it is due to the MS Update and that a good fix is to simply delete the file MSForms.exd from any Temp subfolder in the user's profile. For instance:
C:\Users\[user.name]\AppData\Local\Temp\Excel8.0\MSForms.exd
C:\Users\[user.name]\AppData\Local\Temp\VBE\MSForms.exd
C:\Users\[user.name]\AppData\Local\Temp\Word8.0\MSForms.exd
Of course the application (Excel, Word...) must be closed in order to delete this file.
Here is the best answer that I have found on the Microsoft Excel Support Team Blog
For some users, Forms Controls (FM20.dll) are no longer working as
expected after installing December 2014 updates. Issues are
experienced at times such as when they open files with existing VBA
projects using forms controls, try to insert a forms control in to a
new worksheet or run third party software that may use these
components.
You may received errors such as:
"Cannot insert object" "Object library invalid or contains references
to object definitions that could not be found"
Additionally, you may be unable to use or change properties of an
ActiveX control on a worksheet or receive an error when trying to
refer to an ActiveX control as a member of a worksheet via code.
Steps to follow after the update:
To resolve this issue, you must delete the cached versions of the
control type libraries (extender files) on the client computer. To do
this, you must search your hard disk for files that have the ".exd"
file name extension and delete all the .exd files that you find. These
.exd files will be re-created automatically when you use the new
controls the next time that you use VBA. These extender files will be
under the user's profile and may also be in other locations, such as
the following:
%appdata%\Microsoft\forms
%temp%\Excel8.0
%temp%\VBE
Scripting solution:
Because this problem may affect more than one machine, it is also
possible to create a scripting solution to delete the EXD files and
run the script as part of the logon process using a policy. The script
you would need should contain the following lines and would need to be
run for each USER as the .exd files are USER specific.
del %temp%\vbe\*.exd
del %temp%\excel8.0\*.exd
del %appdata%\microsoft\forms\*.exd
del %appdata%\microsoft\local\*.exd
del %appdata%\Roaming\microsoft\forms\*.exd
del %temp%\word8.0\*.exd
del %temp%\PPT11.0\*.exd
Additional step:
If the steps above do not resolve your issue, another step that can be
tested (see warning below):
On a fully updated machine and after removing the .exd files, open the file in Excel with edit permissions.
Open Visual Basic for Applications > modify the project by adding a comment or edit of some kind to any code module > Debug > Compile
VBAProject.
Save and reopen the file. Test for resolution. If resolved, provide this updated project to additional users.
Warning: If this step resolves your issue, be aware that after deploying this updated project to the other users, these users will
also need to have the updates applied on their systems and .exd files
removed as well.
If this does not resolve your issue, it may be a different issue and
further troubleshooting may be necessary.
Microsoft is currently working on this issue. Watch the blog for
updates.
Source
It was KB2553154. Microsoft needs to release a fix. As a developer of Excel applications we can't go to all our clients computers and delete files off them. We are getting blamed for something Microsoft caused.
I'm an Excel developer, and I definitely felt the pain when this happened. Fortunately, I was able to find a workaround by renaming the MSForms.exd files in VBA even when Excel is running, which also can fix the issue. Excel developers who need to distribute their spreadsheets can add the following VBA code to their spreadsheets to make them immune to the MS update.
Place this code in any module.
Public Sub RenameMSFormsFiles()
Const tempFileName As String = "MSForms - Copy.exd"
Const msFormsFileName As String = "MSForms.exd"
On Error Resume Next
'Try to rename the C:\Users\[user.name]\AppData\Local\Temp\Excel8.0\MSForms.exd file
RenameFile Environ("TEMP") & "\Excel8.0\" & msFormsFileName, Environ("TEMP") & "\Excel8.0\" & tempFileName
'Try to rename the C:\Users\[user.name]\AppData\Local\Temp\VBE\MSForms.exd file
RenameFile Environ("TEMP") & "\VBE\" & msFormsFileName, Environ("TEMP") & "\VBE\" & tempFileName
End Sub
Private Sub RenameFile(fromFilePath As String, toFilePath As String)
If CheckFileExist(fromFilePath) Then
DeleteFile toFilePath
Name fromFilePath As toFilePath
End If
End Sub
Private Function CheckFileExist(path As String) As Boolean
CheckFileExist = (Dir(path) <> "")
End Function
Private Sub DeleteFile(path As String)
If CheckFileExist(path) Then
SetAttr path, vbNormal
Kill path
End If
End Sub
The RenameMSFormsFiles subroutine tries to rename the MSForms.exd files in the C:\Users\[user.name]\AppData\Local\Temp\Excel8.0\ and C:\Users\[user.name]\AppData\Local\Temp\VBE\ folders to MSForms - Copy.exd.
Then call the RenameMSFormsFiles subroutine at the very beginning of the Workbook_Open event.
Private Sub Workbook_Open()
RenameMSFormsFiles
End Sub
The spreadsheet will try to rename the MSForms.exd files when it opens. Obviously, this is not a perfect fix:
The affected user will still experience the ActiveX control errors when running the VBA code the very first time opening the spreadsheet. Only after executing the VBA code once and restarting Excel, the issue is fixed. Normally when a user encounters a broken spreadsheet, the knee-jerk reaction is to close Excel and try to open the spreadsheet again. :)
The MSForms.exd files are renamed every time the spreadsheet opens, even when there's no issue with the MSForms.exd files. But the spreadsheet will work just fine.
At least for now, Excel developers can continue to distribute their work with this workaround until Microsoft releases a fix.
I've posted this solution here.
With Windows 8.1 I couldn't find any .exd files using windows search. On the other hand, a cmd command dir *.exd /S found the one file on my system.
Advice in KB and above didn't work for me. I discovered that if one Excel 2007 user (with or without the security update; not sure of exact circumstances that cause this) saves the file, the original error returns.
I discovered that the fastest way to repair the file again is to delete all the VBA code. Save. Then replace the VBA code (copy/paste). Save. Before attempting this, I delete the .EXD files first, because otherwise I get an error on open.
In my case, I cannot upgrade/update all users of my Excel file in various locations. Since the problem comes back after some users save the Excel file, I am going to have to replace the ActiveX control with something else.
The best source of information and updates on this issue I could find is in the TechNet Blogs » The Microsoft Excel Support Team Blog (as mentioned):
Form Controls stop working after December 2014 Updates (Updated March 10, 2015)
On March 2015 a hotfix was released in addition to the automated fix-it and manual instructions, and it's available on Windows Update as well.
The latest update and fix from Microsoft:
3025036 "Cannot insert object" error in an ActiveX custom Office solution after you install the MS14-082 security update
STATUS: Update March 10, 2015:
Hotfixes for this issue have been released in the March 2015 Updates for Office 2007, 2010 & 2013.
General info about the problem:
For some users, Form Controls (FM20.dll) are no longer working as expected after installing MS14-082 Microsoft Office Security Updates for December 2014. Issues are experienced at times such as when they open files with existing VBA projects using forms controls, try to insert a forms control in to a new worksheet or run third party software that may use these components.
https://technet.microsoft.com/en-us/library/security/ms14-082.aspx
You may receive errors such as:
"Cannot insert object"; "Object library invalid or contains references to object definitions that could not be found"; "The program used to create this object is Forms. That program is either not installed on your computer or it is not responding. To edit this object, install Forms or ensure that any dialog boxes in Forms are closed." [...]
Additionally, you may be unable to use or change properties of an ActiveX control on a worksheet or receive an error when trying to refer to an ActiveX control as a member of a worksheet via code.
Manual and additional solutions:
Scripting solution:
Because this problem may affect more than one machine, it is also possible to create a scripting solution to delete the EXD files and run the script as part of the logon process using a policy. The script you would need should contain the following lines and would need to be run for each USER as the .exd files are USER specific.
del %temp%\vbe\*.exd
del %temp%\excel8.0\*.exd
del %appdata%\microsoft\forms\*.exd
del %appdata%\microsoft\local\*.exd
del %temp%\word8.0\*.exd
del %temp%\PPT11.0\*.exd
Additional step:
If the steps above do not resolve your issue, another step that can be tested (see warning below):
On a fully updated machine and after removing the .exd files, open the file in Excel with edit permissions.
Open Visual Basic for Applications > modify the project by adding a comment or edit of some kind to any code module > Debug > Compile VBAProject.
Save and reopen the file. Test for resolution.
If resolved, provide this updated project to additional users.
Warning: If this step resolves your issue, be aware that after deploying this updated project to the other users, these users will also need to have the updates applied on their systems and .exd files removed as well.
Simplified instructions for end-users. Feel free to copy/paste the following.
Here’s how to fix the problem when it comes up:
Close all your Office programs and files.
Open Windows Explorer and type %TEMP% into the address bar, then press Enter. This will take you into the system temporary folder.
Locate and delete the following folders: Excel8.0, VBE, Word8.0
Now try to use your file again, it shouldn't have any problems.
You might need to wait until the problem occurs in order for this fix to work. Applying it prematurely (before the Windows Update gets installed on your system) won't help.
I did finally find this answer on the official Microsoft KB:
http://support.microsoft.com/kb/3025036/EN-US
No new information here than what we have in previous answers, but at least it acknowledges that Microsoft is aware of the issue.
I know many answers have already been posted for this, but neither one answer independently worked for my site. So here is what worked for me:
Step 1: Uninstall the following updates - KB2920789, KB2920790, KB2920792, KB2920793, KB2984942, KB2596927
Step 2: Hide these updates so they do not get installed on subsequent reboots
Step 3: Delete folder Excel8.0 from C:\Users\<>\AppData\Local\Temp
Step 4: Restart workstatiion (I would also make sure the above mentioned KBs did not inadvertently get applied)
I want to provide an answer that worked as the only thing for me (I realize that I might be the only one ever). I had in one macro that I was calling using the ribbon. It had the following code:
colStore = new Collection
I wasn't aware that it throws an error so I was baffled and tried everything in here. The button just stopped working and I couldn't get it to work. When I noticed the error and corrected it to:
Set colStore = new Collection
It started working again. Absolutely strange if you ask me but maybe it helps someone out there who was as desperate as me.