I have created a simple VSTO project based on a Binary Excel file, the name of the file is Text.xlsb. When I run this in debug mode from VS, the file gets renamed as Test1.xlsb and opens, also my open even is not getting fired, but the Activate event if triggered.
Can some one help me to resolve this? I think VSTO is treating the Excel file as a template and assigning a different name on open.
Related
My program at the very end uses the below code to open an Excel file, it is the final line of code too:
os.system(f'start EXCEL.EXE "{file_name}"')
Excel starts fine and opens the file with no issues since the file is in the current working directory. After Excel opens and I select "Enable Editing", it requires me to reopen the file in Excel with the below notification:
Excel Reopen File Notification
The author of the file is openpyxl immediately after it first opens, so I think that the newer version it is referring to has to do with openpyxl still affecting the Excel file while I have it open. I am using Microsoft Office 365 with Autosave feature on. I cannot figure out how to prevent this from happening. I use a with statement as my context manager to write out the various dataframes to the sheets, so to my knowledge, the file should be closed once the code executes through the context manager. I hope this is enough info, I am new to coding (I am doing this to automate some of my day-to-day job tasks).
I haven't been able to think of anything that might prevent the file from having me reopen to a newer version since I thought the with statement context manager closes the Excel file so openpyxl shouldn't be able to touch it after that code block executes.
I have a bug in an Excel VSTO 4.0 C# add-in that I've developed but it is only occurring when double-clicking on an existing file to launch Excel. I'm trying to figure out a way to start the VS2013 debugger so that I can put in some breakpoints but none of the ways I've tried to start the debugger mimic the process of launching Excel by a double-click on a file.
Ways I've tried so far:
Launching Excel itself and then attaching to the process
Double-clicking an Excel file and then attaching to the resulting process
In the VS project Debug properties under Start Action, entering the path to Excel Excel.exe in the Start external program box and the path to an existing Excel file in the command line arguments box
Adding Excel.exe as a new existing project to my VS solution with the path to an existing file as an argument in the project properties, the setting it as the startup project for the solution.
None of these methods for starting the debugger are reproducing the bug. Is there another way to start debugging when double-clicking a file to launch Excel?
For what it's worth, the bug I'm experiencing is that an empty workbook will be created when double-clicking an existing file when Excel is not already running. I need to find out where / why that empty file is getting created. It doesn't happen if Excel is already running and you double-click a file to open it.
This works for me:
private void ThisAddIn_Startup(object sender, System.EventArgs e)
{
System.Diagnostics.Debugger.Launch();
...
}
Try to use any logging mechanisms to log any action in the code. Thus, you will be able to find what is going on in the code at runtime. For example, you can write actions to the log file. You may find the log4net library helpful.
I am assuming that you are puuting breakpoint in a method which handles the WorkbookOpen event.
When you double click an Excel file, it gets loaded and event WorkbookOpen is raised. VSTO add-in is not yet loaded so you can't get that event. After loading the workbook, Excel loads VSTO add-in.
So when your add-in is loaded, your handler for AddinStartup comes in action.
In vb.net, the handler line appears as...
Private Sub ThisAddIn_Startup() Handles Me.Startup
You can now check for loaded workbook in ThisAddIn_Startup
If Application.ActiveWorkbook IsNot Nothing Then
DoSomething(Application.ActiveWorkbook)
End If
The other way to mimic some of these debugging is to open file and close file, loading and unloading your addin using excel options manually.
Put a breakpoint on Addin_Startup.
Start normal debugging of VSTO Project.
Load File.
Go in excel options and unload your addin by unchecking it.
Go in excel options and LOAD your addin by checking it.
I have been using Microsoft Excel 2003 since it first came out and am only just coming across an apparent problem with it. I have a number of .xlt files that are used throughout the company and have never had any issues with them. However, it has just come to light that there is a user who can change the template.
Ordinarily you open the Template file (e.g. Template.xlt) and on opening it find it is called Template1. On pressing the save icon you are taken to the the Save As screen with the default option to save the file as Template1.xls in MyDocuments (Default location).
In this one case though, the user opens the file as Template, and on pressing the save icon overwrites the original .xlt file. I have never seen this before and am bamboozled. Any ideas please?
How exactly does the user open the template?
If a template is opened by double clicking the .xlt (or .xltx/.xltm) file in Windows Explorer, the template generates a new Excel file based on the template.
If an .xlt (or .xltx/.xltm) is right-clicked in Windows Explorer and then the "Open" command is selected in the context menu, then the template file itself will be opened.
If an .xlt (or .xltx/.xltm) template file is opened via Excel's File > Open dialog, the template file itself is opened.
A shortcut that leads to an Excel template behaves in this way:
double-click - creates a new file based on the template.
right-click > New - creates a new file based on the template.
right-click > Open - opens the template itself.
Edit: if the behaviour of double clicking a template file (or a link to a template) occurs only for one user, you may want to unregister and re-register Excel 2003.
Quoting from this question at the Microsoft Answers forum:
> Start>Run>excel /unregserver
> - note the space between excel and /unregserver then
> Start>Run>excel /regserver
> - again note the space between excel and /regserver
I know it's not the best form to answer your own questions, but hopefully someone else will be able to benefit from the solution that I have found.
In order to solve this, download and install a program named FileTypesMan.
Run the program and find the .xlt extension. In an ordinary working system this will have at least New and Open as options with New set to default. In this case there was only Open as an option. Create an option for New and set this to default.....Presto, sorted.
I have Office 2007.
Each time I launch Excel, or open an existing file, it tries to access some old file and I get the following error pop up:
'E:\xyz.txt' could not be found. Check the spelling of the file name, and verify that the file location is correct.
If you are trying to open the file from your list of most recently used files, make sure that the file has not been renamed, moved, or deleted.
Please help on this.
Thanks in advance!
Maybe you have an old add-in still active?
Developer > Add-Ins
if you see any custom add-ins, deactivate them and see if the problem remains.
Alternatively you could check in the VBA window what xla / xlam files are active and see if the file you mention is hiding somewhere in the code thereof
I have a c# application that uses Microsoft.Office.Interop.Excel. The application runs for a long period of time! If I try to open Excel manually on a different worksheet from the one the c# application is processing the c# application fails with some HResult cryptic message.
Is there a limitation with Microsoft.Office.Interop.Excel in that only 1 excel process can run at once?
Any information around this issue would be great!
thanks for any help!
Mostly, it is how your code is interacting with Excel that is the problem. Many people use ActiveCell, ActiveWorkbook, and so on. Therefore, when you open another workbook during this process, you will generate some kind of error. To avoid this, open another instance of Excel. In our shop, we created a shortcut in our "Send To..." folder. We could then just right-click on the file in Windows Explorer, select "Send To..." menu, then click on our shortcut. This saved us from having to open Excel, select file open, browse to file, and so on.