I initially created two new modules in a fresh workbook. I accidentally used the "Export File..." feature in the Visual Basic project explorer. This created two new .bas files.
The problem is that now that I have these two objects, they are opening up every time I attempt to launch excel. The files appear to be save in this directory: C:\Users\f370830\AppData\Roaming\Microsoft\excel\XLSTART. Excel points to this directory when I try to save either the VBA object or the excel book that they launch in.
I do not see the files in this directory. I even deleted the directory using both windows explorer and the command line. However these files still show up my VBA project explorer and launch in new windows when I start excel.
Any suggestions for how to delete these files and prevent them from launching every time I start excel?
I was able to solve the issue. Like I mentioned in my comment above, I was able to track down the directory storing the two rogue .bas files using the SysInternals program Process Explorer. The files were being saved here:
C:\appsensevirtual\S-1-5-21-1781428526-1902518210-316617838-164488\{B0970185-A624-496C-BE3B-08CE8AAA200A}\_Microsoft Office 2016\Device\HarddiskVolume1\Users\f370830\AppData\Roaming\Microsoft\Excel\XLSTART
as opposed to the normal 'users' directory. Just deleting the .bas files did not stop the two workbooks from launching when I open excel. For some reason opening excel would recreate the .bas files in the XLSTART folder.
I just deleted the entire XLSTART folder, which solved the problem. A new XLSTART folder was created on my next excel launch.
One small side effect is that excel now opens into a grey screen as opposed to a fresh worksheet. But that isn't a big deal to me, 9 times out of 10 I am opening existing workbooks.
On windows, open the workbook in question. Once opened, press ALT+F11 to open up the VBA editor. From there, right click on the module you want to delete in the left-hand navigation pane, and select DELETE (may be called REMOVE). Excel will likely prompt you to export the module again before removing it; I would suggest saving a copy somewhere but this is entirely up to you.
This worked for me:
*************** How to remove the personal.xlsb vba project *******************
Step 1:
On Windows Explorer
*Click on view tab at the top, three options to the right of file
* Click on options
* On the drop down menu click on change folder and Search options
* Go to view then click show hidden files, folders, and drives
* Click apply
* Note, the Personal.xlsb is a hidden file thats why the above is done first
Step 2:
On windows explorer
* Go to Windows-SSD(C:) i.e the C: folder
* Double click Users
* Double click the user in question, Username
* Double click AppData
* Double click Roaming
* Double click Microsoft
* Double click Excel
* Double click XLSTART
* you should find the "Personal.xlsb" Microsoft Excel binary worksheet
* Select and delete
Reference:
https://www.youtube.com/watch?v=EXN-nKwfZ5o
"Any suggestions for how to delete these files that still show up my VBA project explorer and launch in new windows when I start excel and prevent them from launching every time I start excel?"
You apparently cannot delete an active VBA project if it is running. Close down Excel. Right-click and Open the file containing the VBA Project while holding the Shift key (this disabled Macros from running). In the worksheet you will see a message "SECURITY WARNING Macros have been disabled", DO NOT enable Macros.
Go to Developer tab | Visual Basic, right-click Module1, and Remove module should not be greyed-out. Save and exit. If all the modules are removed from the Project, the Project is removed as well. The principle may be that if the module or code or ActiveX control is being used, it won't let you delete.
Related
I am learning EXCEL vba and was trying to create a macro that ran when EXCEL was opened. It was saved as "Personal Workbook" and now every EXCEL spreadsheet I open has this macro. Should have selected as "This Workbook". How do I get rid of that macro so that Workbooks open without it.
Thanks
The personal workbook will be in Appdata/Microsoft/Excel/XLSTART. Just remove it from there. To get to your app data folder press windows+r and type %appdata%
If you just want to remove the module in Personal workbook that was created, rather than the whole file:
In the Visual Basic Editor (Alt + F11 to open)
Find the PERSONAL.XLSB VBA Project in the Project Explorer (Ctrl + R to open in the VBE)
Press the little + sign next to VBAProject.
Press the little + sign next to the Modules folder in the project.
Find the module containing the code, right-click the module and select Remove ModuleName
Using the gui to get to the file.
In Excel
File -> Options
Click on "Customize Ribbon"
In the right hand pain there is a "Developer" checkbox that is unchecked by default, check it.
Now go to the "Developer" ribbon and click "Macros"
Click the macro you do not want an click "Delete".
I have written some code for an excel spreadsheet. This sub has been added to the ribbon using the standard customizations found in File -> Options -> Customize Ribbon. What is funny though, is that the customization will run the Sub on the EXACT EXCEL FILE that the Sub is written in, i.e. the original.
My users copy the excel file and make adjustments and then run the sub (by clicking the customized button in the ribbon), which then opens the ORIGINAL template file and runs the code. This actually works fine - and I like it because it runs the TEMPLATE code on the ACTIVE sheet. But the only problem is it is also OPENING the original template file. How do I get it to close? Remember it is not the ActiveSheet anymore.
One possible answer is to check if the template is open, then close it (using a static reference), but I would prefer something a little more elegant than that.
You should be able to find the template/original using ThisWorkbook.
Also, if you deliver your workbook's code as a .xlam instead of .xlsm, it will be opened, but there won't be a window for it, so users won't see it.
Not sure if you're using this already, but you might also want to use "for this workbook only" when adding ribbon buttons for a .xlam . (Delivering as .xlam allows you to install buttons from a workbook into the ribbon, without relying on file path and without needing your users to also install buttons (they install .xlam instead).)
Hi I have an Excel 2003 application which has a listview embedded in the worksheet. It no longer works on Excel 2010.
I re-registered the ocx using regsvr32 C:\Windows\System32\MSCOMCTL.OCX as per advice.
This works for listviews on forms, but not for the worksheet.
Microsoft advises that Cannot insert object can be generated if the control is form specific and an attempt is made to add to the worksheet.
Can the listview be used in Excel 2010 on a worksheet
If so how?
Otherwise a rewrite will be required.
That happened to my Excel files using ActiveX or any sort of automation. The solution was confused at the beginning but the following link will help you.
Create a batch to remove cached control type libraries (extender files *.EXD) files from Windows
Opening each of the projects (Excel with macros)
Switch the file to design mode
Open VBA Code (Alt-F11) to edit any module and press from the main menu > Debug > Compile VBAProject
Switch back to Run Mode
Save and Close File
Reopen the file & test
Form Controls stop working after December 2014 Updates
This post is about installing XLAM's without creating links. (Everyone hates links). Consider the trivial addin:
Public Function UDF_HELLO(x)
UDF_HELLO = "Hello " & x
End Function
Put this code and nothing else into a Module and save as "Hello.xlam" on the Desktop (and NOT in the default excel addins folder). Next, while HELLO.XLAM is still open, create a new XLSX workbook with the formula
=UDF_Hello("world")
in cell A1, which simply displays "Hello world" in that cell. Save the workbook and exit Excel. Now, if you reopen the workbook without the XLAM, Excel will complain about "links to other sources ...". Whether you click "Update" or "Don't Update", Excel will mangle the formula in cell A1 like this:
='C:\Documents and Settings\tpascale\Desktop\Hello.xlam'!UDF_Hello("world")
Very often this "forced-linkage" is NOT desirable. In my computing environment there is a lot of ad-hoc analysis and it makes no sense to impose an install regimen on every XLAM we throw together to solve the problem of the day. I just want to hand out XLAM files to users and let those users open them when they need them, WITHOUT having to worry about the slightest mis-step causing their formulas to get mangled.
QUESTION:
Is there a way to instruct Excel to NEVER construct external links for UDFs, and simply to use UDFs if they're loaded and return #VALUEs otherwise ?
I don't know of a way around this with .xla/.xlam add-ins.
But this issue does not occur with .xll add-ins.
These can be created in C using the Excel 2010 SDK, or in managed languages like VB.NET or C# using the free Excel-DNA library.
(Disclaimer: I'm the developer of Excel-DNA. This issue is one of the reasons I went with the .xll interface for making managed UDF add-ins.)
You can have them open the .xla file and have an Auto_Open procedure install the add-in.
http://www.vbaexpress.com/kb/getarticle.php?kb_id=693
After excel closes you can have the add-in uninstall itself.
oAddIn.Installed = False
You can give your add-in a setting for the user to not uninstall after every use by using a worksheet named something then have cell A1 equal to true or false.
I haven't tested this but hopefully it works for you.
This should work to resolve your issue though it does not instruct Excel regarding external links. I have tested it myself by creating the XLAM, saving it to my desktop, installing it in the Excel add-ins and then using it on a new workbook.
Steps:
Once you have saved the add-in, close it.
Go to Excel Options-->Add-Ins
In the Manage drop-down select Excel Add-ins and press 'Go'
In the 'Add-Ins'dialogue that appears click 'Browse' and navigate to
the add-in you just created. Select it and hit 'Ok'
If prompted to save the add-in in the add-ins folder, select 'No'.
Selecting 'Yes' may cause an error if the add-in file suffix does
not match the version of Excel being used.
Your add-in should appear in the 'Add-Ins available' scrollbox,
check its box and hit 'Ok'
Your add-in should now be active whenever you open Excel.
Test this by opening a new workbook and try using your UDF.
Best,
I usually solve this problem by:
Saving an XLA/XLAM file (outside Personal folder, of course)
Connect to it in Tools - Addins
Write pseudo macros in your current Excel file that links to those macros / functions in the XLA/XLAM file.
See the detailed instructions in my reply here.
I have an Excel 2007 Sheet with Macros. When I click on a button, it immediately pops up an error "File Not Found: VBA6.DLL"
Problem is, I have been using this sheet forever, and never seen this problem before. I did make some very very minor changes to the Macro code.
And, I have 2 other sheets with identical macro code which I made the same changes to. And those two sheets run fine.
Any ideas?
In this order:
Check your references (Alt+F11, Tools-References) to see if any are marked MISSING and make sure that Visual Basic for Applicatiions is checked.
Check the directory C:\WINDOWS\system32 for VBA6.dll
You may need to register VBA6.dll (Start->Run)
Regsvr32.EXE "C:\WINDOWS\system32\VBA6.dll"
I had the same problem with a shared file. The fix was as follows:
Un-share the file
Copy all macros; sheets, this workbook, modules and saved them in a text format.
Save the .xlsm as a .xlsx file
Save back to .xlxm file
Paste all macros back in
Reset shortcut keys and descriptions in macro options
Re-share the file
This worked without having to go to IT and get someone with administrative credentials to fix it.