My issue with the unsaved file is if I clear the clipboard with:
Globals.ThisAddIn.Application.CutCopyMode = False
The errors I get for the clipboard code is:
System.Runtime.InteropServices.COMException
HResult=0x800A03EC
Message=Exception from HRESULT: 0x800A03EC
Source=<Cannot evaluate the exception source>
StackTrace:
<Cannot evaluate the exception stack trace>
The code works ok but this issue with the clipboard happens when I change anything in the draft excel sheet and work on it while being unsaved. So a work-around I found is to save the excel file whenever I change values, but unfortunately, that is not what I want.
Is there a way to work on the unsaved excel file with VSTO, do I need to open an xls/worksheet from Temp?
Edit1: Another good observation, if the app changes the saved excel file, I have the option to save the file so that means its unsaved, but if I run the app again it works on the unsaved file. But any manual changes on the excel triggers the error. Observation 2, any changes made by the app cannot be undone with the undo operation. There is no option on the gui and ctrl-z doesn't do anything.
Edit2: It is as if Globals cant fetch the excel file if it's modified by the user manually.
Related
I am working with openpyxl to make changes to a file and then save it.
Among the lines that are used to this, the one that gives me trouble is:
wb = openpyxl.load_workbook(filename=sheet_loc, read_only=False,keep_vba=True)
I know for a fact that the "keep_vba" is a very dangerous parameter, because if you call it True when you are saving a .xlsx file, the file will get corrupted. And vice versa.
Now, this is exatcly what happened to me. I had a .xlsx file and I wrote "keep_vba=True", so the workbook is corrupted. This is what I receive when I'm trying to open it:
My question is: Is there any way to fix that ? To recover this sheet ? I've tried "Open and repair" button, but it didn't work, it just gives me the same error said above.
I was having this same problem and I got the solution today.
To clarify, what you did here with openpyxl was nothing more than "turning" vba on for this workbook, but since the workbook still is a .xlsx file, it does not support this kind of thing.
To recover this file, you just have to change the type of the file to .xlsm, you can do this on windows by simply renaming it from "workbook.xlsx" to "workbook.xlsm".
I'm encountering an issue trying to get some macros and VBA scripts working on a new coworker's computer. I've been using the same code for years on my machine and several others without issue, but when my new analyst tries to run it, it throws an error stating it couldn't save the file. He can manually save the file without issue, but running the script throws the error. The really weird part is that it lists the file path, but replaces the filename with a seemingly random hex byte.
On another file, if he opens it, closes with or without saving, then I open the file and try to save it using a macro, it fails saying "cannot access file...". If I copy and paste the file, open and run the macro again, it saves over the offending file no problem.
We've checked permissions and settings and haven't found anything that was different between the two systems. We're both on VMs. His hardware allowance is less than mine but otherwise they're both IT-managed and identical. I'm at my wits' end... Any advice on what may be the source of my grief would be helpful, even if not a solution.
A couple of things I'd check before trying to step through debugger mode.
Coworker does not have write access to the directory (I think you said you checked already)
The new users' Trust Center Settings are not correct
File > Options > Trust Center > Trust Center Settings... > Macro Settings > Ensure the box is checked to trust the VBA model and that macros are not disabled
The new user does not have the same libraries referenced.
Alt + F11 > Tools > References... > Check if coworkers' libs match yours
Is he using a new/different version of Excel that you? A lot of older code got bojangled when Office 365 hit the scene.
After checking settings, I would ask the following:
What error is thrown when coworker attempts to run the macro?
When does the error get thrown? It could be that you have code that is attempting to edit the file (or has another file stuck in an edit) at the same time you're trying to save it.
I would see why the file name is getting corrupted. It sounds like coworkers' machine is looking to a bit of memory or memory address that is somehow getting forgotten. Like the code is referencing a variable that is out of scope.
User Access Control has been enabled on his VM that is somehow preventing him from saving the file correctly.
Your code does not properly Quit the Excel application, so its still running in the background on coworkers' machine. Have them open/close without saving a file and check Task Manager to see if Excel is still up to confirm
I use an XLAM file to store a few subs for general spreadsheet purposes. The XLAM is added and checked in the VBA editor's references and has worked for 4+ months without any issues. Most of the functions are pretty basic, like creating PDF's or refreshing connections in whatever spreadsheet calls the subs that reside in the XLAM file.
A few days ago, none of my morning processes ran, and when I checked what happened I had 10 "recovered" files which, when I went to check repairs, Excel said there was nothing wrong with them. I tried to step through the subs to see where they failed, but each one crashed without an error message from VBA, they just failed completely. I tried running the macros through a vbs file called from Powershell and I received the message "The remote procedure call failed" on the line which called the macro.
I did not change any code in any of my workbooks or in the XLAM file, nor did I change the references to the XLAM in any way. In addition, the code consistently works on my co-worker's machines.
I've been calling the functions from the XLAM file as follows:
Call Project.Module.Function/Sub(argument)
Maybe it is an issue with the RPC but I really do not know, any help would be greatly appreciated, and I'm happy to post more code.
I have a vba macro to open Excel files, including Read-only files.
I use the following code to do this:
Workbooks.Open((FileName:=MyFileName, UpdateLinks:=0, IgnoreReadOnlyRecommended:=True)
Up until June 2013 this never failed. As of now this no longer works. Now when the macro encounters a read-only file the file appears in a separate window and a Save As prompt also appears (never happened before).
If I click Cancel I get a Path not found error. If I click Save the file gets saved to its original location. This is completely new. There is no Save As command in this part of my code.
It appears to be something new associated with Microsoft’s File > Protect Workbook > Mark as final stuff. Anyone seeing this? I can’t find a way to prevent it. I simply want to be able to open the read only file without further prompts.
I haven't used VBA with excel much, but is it possible that the macro security settings within excel were reset so that it no longer trusts macros or VBA script attempting to use it.
Thanks for the input. I did find a work-around. In newer versions of Excel there is a new ReadOnly designation: Final, i.e. File > Protect workbook > Mark as Final. This is the same as ReadOnly, just by another name, and it does not show up as an option in WorkBooks.Open(FileName:= ...). If I set the Workbook.Final property = False, then I can open the file w/o the SaveAs prompt.
If wbName.Final = True Then
wbName.Final = False
End If
i have excel .xlsm file format with about 20000kb file size..i have a macro inside it but the macro runs ok and fast. the problems is it is very slow during opening and closing,taking about few minutes.i then try to change it to .xlsb file format which reduce its size to 2000kb (very huge difference) and the file run fast while opening but still very slow when closing or saving. sometimes closing it make the excel 'not responding'. i have no macro running when opening or closing event. any suggestion on what caused this?
I would suspect the Office file validation slowing things down. Microsoft Update (KB 2501584) can really be a problem while it does it's security checking on a file.