I have an Excel 2016 file (.xlsm). After few weeks working on this file, now I'm facing with one small but weird problem - cannot open ThisWorkbook module. As you can seen in the picture, trying to open this module, window just simply freezes on the screen, any mouse's single or double-clicks on it have no effect.
Maybe somebody also had the same issue? What might cause it and how to resolve it?
this might have only worked for me but is worth a try
clear the office cache (C:\Users\username\AppData\Local\Microsoft\Office\16.0\OfficeFileCache\0)
open the file on a different computer and name it something random.
open the file on the first computer and resave file.
As pointed out in Han's comment, it's possible that the module is corrupted. You may be able to salvage it by right clicking the module and using 'Export File...' to save it as a class file.
If this succeeds you can attempt to recover your code by:
Importing the saved file, this will add 'ThisWorkbook' as a class file that can be opened like other modules.
If this doesn't work, try opening the saved file in Notepad. This should reveal your code in plain text.
I literally have this probablem every day or so. There is no answer, I have to save multiple files everytime I make any changes to the workbook. Its incredibly frustrating when all the macros disapear from the list and you can't open a single module
Related
Having a few issues when opening an external excel file.
Basically we have a system where we use a template excel file that writes to another excel workbook. (Multiple users could be in a template file at any one time)
The code is pretty straight forward in that it opens the file as readonly when extracting information and it opens the file as normal when adding/updating new information.
An issue has arose though with 1 particular user - when they click the button to update it always opens the file as read only (doesn't happen to anyone else) I have tried putting her on a different PC and it worked fine - so I am thinking it must be something to do with her settings on our system.
As anyone else come across this or any ideas how to resolve? (Done a office repair but didn't help)
Thanks
A specific xlsm workbook crashes when I try to save, save as, or when I open the VBA editor. I've tried disabling macros, removing auto calculations, etc. I can't actually get to the code to see if there's a bug causing the crash due to the editor itself causing crashes.
Edit: Also forgot to mention there are links to another workbook in the file - but removing auto-updating/calculating upon save doesn't seem to help. Also, I'm able to modify the workbook, I just can't execute the macros, save, or open the VBA editor.
Edit2: Some additional info. I tried deleting all worksheets and still have the same problems so there must be something wrong in the code.
Looking for a solution to salvage the workbook.
Remove the VBAProject.bin file from the .xlsm file:
copy the .xlsm file
change the extension of the copy to .zip (say Yes to the warning about changing extensions)
open the ZIP file
open the xl folder
cut the VBAProject.bin file and paste it to somewhere outside the ZIP file
rename the ZIP file back to a .xlsm extension
You should now be able to open the .xlsm file in Excel but it will no longer have any macros.
It is theoretically possible to reconstruct the macros from the VBAProject.bin file using the resources linked to in this answer but this may involve considerable effort
Good evening,
I have the following problem to solve:
I want to add to an Excel file the contents of a bunch of user-generated .txt files. These files are generated throughout the day and sent over FTP to a folder, which is being constantly monitored by the program to see if there are new additions.
If the program finds new .txt files in it, it opens the Excel file which is to be edited, adds the info and then closes the Excel, saving the changes.
At the same time, users have to open these Excel files to check the new updated info and deal with it accordingly.
The program's execution is somewhat like this:
Infinite loop checking if the folder is empty or contains new .txt files.
If the folder is not empty (hence there is info to be added), it checks whether the Excel file is open or not.
If the Excel file is closed:
Opens it programmatically and adds the info to it.
Saves the Excel file and quits.
Backups the .txt to another folder in case there was some sort of error.
If the Excel file is open:
Keep checking until it is closed.
To check if the folder is empty or not I use: System.IO.Directory.EnumerateFileSystemEntries(path).Any()
To check if the Excel file is open I use:
System.IO.FileInfo(path) and a FileStream which, inside a Try-Catch clause, opens the FileInfo in the following mode: info.Open(FileMode.Open, FileAccess.ReadWrite, FileShare.None)
For the opening, editing and saving/closing of the Excel file I use Microsoft.Office.Interop.Excel.Application, [..].Workbook and [..].Worksheet.
The main problem comes when a user opens (through the normal Office Application) the Excel file in the middle of the addition process. I was hoping to find some sort of lockage of said file so the user cannot interrupt the editing process.
Any ideas on how to combine both types of opening/editing the Excel file?
Thank you so much in advanced.
TL;DR: How can I prevent, programmatically, a user from opening an Excel file while a program is editing that very Excel? Or at least, open another instance of it so the process is not interrupted?
PS: If any further code should be needed, I'll gladly post it :)
I think you need a better solution. It sounds like you are maxing out the capabilities of Excel. You would be better off, if possible, to use a database.
I'm using Excel 2010. I have some code in background (VBA) that is growing up from time to time. I'm trying to find a way to separate the source code from the xls file, so I could compare the code changes. In other words, I want that the code will be in a textual file, and every time I'll open the Excel file, the source code for macros will be taken from this file.
Thanks in advance!
Take a look at this question on SO.
It has the mention of addin called SourceTools, that I have used & find it worthwhile.
Also, it comes with source code so it can be modified to point it to the source code control software (such as SVN) that is specific to your use.
Feel free to close this question as the link I gave has the same question as yours & answers what I suppose you are looking for.
Have a look at the various code cleaner apps/code available for VBA, such as:
http://www.appspro.com/Utilities/CodeCleaner.htm
Among other things, these export the modules/forms/classes to text files, delete them, then re-insert them into your projects.
With a few mods, that'll form the basis for what you're after.
Another possibility: I don't do much in Excel, but if its add-ins behave like those in PowerPoint, that might help also. In PPT, installed add-ins load automatically when PowerPoint starts, create any user interface needed and are available to use with any open files in the app. To update the code, you modify it, create a new add-in, put it wherever PPT is looking for it, and restart PPT. Voila ... code's updated for all PPT files.
First of all, thank you all for your answers. my solution was:
1. export all the modules to *.bas (one file per module).
2. add the modules code my calling:
Application.VBE.ActiveVBProject.VBComponents.Import (filename)
for each file..
3. after finishing:
Set VBComp = VBProj.VBComponents(moduleName)
If Err.Number = 0 Then 'no error
VBProj.VBComponents.Remove VBComp
that's remove the module so it won't be saved in the xls before quiting
I would recommend a manual process in such a scenario.
Suppose you want to take a backup of Module1, then right click on it and click on "Export File". You will get an "Export File" dialog box. Save it as, say Module1 - 22 Apr - 2012.bas at a relevant location. And you are done
How would this help?
1) The dates in the file name will tell you what date the backup was taken so you can actually keep track of the date when the macro was changed.
2) .Bas files can be opened with Notepad. This will help you in comparing the current VBA code with the relevant backup file.
3) If at any point of time you want to retrieve the backup from a particular date, simply delete the existing module (take a backup of it if you want) and then click on "Import File" and import it in your VBA.
HTH
I'm writing VBA codes for multiple Excel spreadsheets, which will be shared with others from time to time. At some point I find there are lots of duplications in my works. So I want to find a way to share codes in a sort of Excel add-in, like the .xla file.
But when I tried to save the Excel file containing shared codes as .xla file, I got some problems:
The file cannot be edit anymore after I save it in the default add-in folder
If I move the .xls file to a folder other than the add-in folder, and open it directly - I cannot use its classes - which creates problems for sharing the codes
Any ideas to create add-ins in a flexible and powerful way please?
Thanks a lot for the help
Not completely sure this is what you're looking for, but ...
(1) save the .xla/.xlam code by clicking the save icon in the VBA editor. HOWEVER, the thing that saves is the thing currently selected in the Project Explorer pane, which lists all open VB Projects and which is usually on the left. Even if you are staring at your just-edited VBA code, clicking the save icon will not save your code unless it is also selected in the Project Explorer pane. You won't get feedback that anything was saved - but you can verify by checking the file timestamp in a separate window.
(2) if you have an *.xls file which (via the formula bar) refers to VBA functions from your *.xla / *.xlam file, then if you open the *.xls file without opening the .xla,.xlam file first, Excel may create external links to resolve the formulas (i.e. referring to a file which is not open). If you have moved or renamed the *.xla file you can get stuck with those "mangled formulas" and need to edit out the pathname links that Excel inserted using a global substitute. If you arrange to open the .xla,.xlam prior to any *.xls file that uses it, you shouldn't have a problem (e.g. by using the default folder).