I'm trying to get a simple VBA function to run in an excel (.xlsm) worksheet.
I created this function:
Function abc()
abc = 2
End Function
in Module2, and it worked.
But after I copied the spreadsheet to another system, it now just shows "#name" as if it can't find it. The function shows up on the available list of functions however.
This makes me think there is some kind of setting I need to enable, but I've enabled whatever I was prompted for. Any ideas?
I should've known it was in the trust center:
http://office.microsoft.com/en-us/excel-help/change-macro-security-settings-in-excel-HP010096919.aspx
Basically, hit the ball and poke around until you find "trust" and "enable macros" and select the least secure options.
And then close and re-open the spreadsheet.
I think we may need more information. What version of Excel are you using? Is it different from the destination system version?
You'll want to make sure that Module2 was in the Workbook you copied into the other system. Excel 2007 stores macros on a personal workbook by default sometimes so you'll need to check the the code is actually inside of the .xlsm file.
If you're still stuck and need a quick fix just copy the code text into the new system's Excel workbook directly without making a .xlsm file (create new module in the other system then paste).
If you would like to learn how to put together add-ins you can get started here or here.
Related
I wanted to save all my VBA Project in a Excel workbook (or other type of file if possible) and then embbed it to run in another workbook. I've seen topics about it but only found ways to run the macros opening the first sheet.
I want to run a macro from a first workbook in a second one without opening the first workbook to do it. How can I do that?
Save the file with the macros as a xlam file and Excel can load them each time Excel opens.
You need to open File -> options -> add-ins.
At the bottom there is a button Go to (or something, I don't have English Excel on the current computer.)
Then add the file to the list by clicking Browse and finding the file you just saved as xlam file.
Two scenarios comes to mind:
1) You have a second macro for personal use and can save it locally (save in: %USERPROFILE%\AppData\Roaming\Microsoft\Excel\XLSTART). This will allow you to create quick-buttons for your macros, etc. These types of macros open with Excel and will be separate VBA Projects inside of the default VBA editor.
2) You have a network or drive that multiple users need to access, so each user has a macro in their file (.xlsm or .xlsb), where that internal macro reads Application.Run "filepath\workbookname.xlsb!macro", which also allows you to call a private subroutine (note that you could use Call, but Application.Run will ensure that even Private macros are able to be accessed). This shouldn't require the other workbook be open, though I have personally had one user whose computer always opens the other file, regardless.
Edit:
Third scenario (really 2b):
3) You have files where you want to regularly access another file... you will follow a similar approach to point 2 where you make a macro to Application.Run, though you can save that macro in your XLSTART folder... this will allow you to have a source macro location where others may also want to access and utilize. The source document would allow you to maintain 1 file for many users.
Your answers were great! Great to know about XLSTART folder from #Cyril, but based on #Andreas answer I found my path.
The "problems" with adding an Add-In as #Andreas said, are cause my VBA Project would be avaliable on the VB Editor to every workbook on that computer, and to run my macros I'd have to use Application.Run("workbook.xlam!Macro").
Then I found References, which I have the same features, including I can delete my .xlam file to remove my code, and don't have the problems I mentioned above.
Adding my VBA .xlam file as an reference, it'll be avaliable only to that specific workbook and I can run my macro just like it was on the same workbook.
For general knowledge:
ADDING A REFERENCE:
1- Save your project as an Excel Add-In (.xlam file)
2- Open your target workbook, go to the Visual Basic Editor
3- Go to Tools > References > Browse... find your .xlam file and make sure it's checked.
4- Done! Now you'll see the project on the editor and can run your macros just like it was on the same workbook.
I created some Excel macros with VBA, saved it as .xlam file. I copied the file to another computer (running Excel2013) and put it in the following folder:
%UserProfile%\AppData\Roaming\Microsoft\AddIns
I enabled the Add-In from Excel > File > Options > Add-ins. Now I want to add those macros to Quick Access Toolbar(QAT). In the QAT options, I choose "Macros" from drop-down menu. The macros didn't show up as I had expected. The list is blank.
My subs do not have parameters if that matters. I have searched the forum and Google with no luck. What else I can check? Thank you!
I experimented with one of my own add-ins. All the subs in a general module were visible; however, none of the functions were. (Even the functions with no parameters -- tested by changing Sub to Function temporarily. The switch resulted in that macro disappearing from the macro list.)
Since you don't mention if there was this issue on the first computer; I am assuming that you would see the same thing there, if you checked.
If you sometimes need a return value from those macros, could you create "calling" macros? Subs which call those functions? If you never need a return value, I would recommend just changing the designation from Function to Sub on the relevant macros.
You could also check out this answer on how to add a button to the excel ribbon via add-in code. This could be useful if you plan on moving the add-in between multiple computers.
Foolish me!
I saved the macro module into personal.xlsb. However, I was trying to export it by creating a blank spreadsheet (e.g. "Book1.xlsx") and save it as Excel Add-In (e.g. "Book1.xlam"). Of course the Book1.xlam won't contain any macro!
I apologize for newbie mistake.
I wrote an Excel add-in that provides UDFs (user-defined worksheet functions).
All is well until one user sends his workbook using those functions to another user, or just tries to use the workbook on more than one computer, where the add-in has been installed to different paths.
Even if the only difference in the paths is the drive letter, when the workbook is opened on the other computer, the old full path appears on the formulas in front of all the UDFs, and the formulas return an error.
One way of dealing with that is doing a search & replace of all formulas in the workbook, replacing the path with an empty string. Then the formulas reset themselves for the add-in's path on the current computer. Sometimes I then have to go into the VBE and run a CalculateFullRebuild to get the formulas to work. Though it works, it's a lot to ask of the less technical users, and it's annoying to have to do it frequently for those users who move their workbooks around a lot.
Also -- do COM add-ins have this problem? My add-in is an xla. Though I'm curious about that, it's a moot point in this case since COM add-ins don't work on Macintosh Excel and I need this add-in to work cross-platform.
UPDATE:
As requested, here's a screenshot:
This screenshot shows what happens if Fred, who put the add-in in C:\Fred's Stuff\Fred's Excel Stuff\MyAddin.xla, sends his workbook to Martha, who put the same add-in in another path, such as C:\Martha's Files\Martha's Excel Files\MyAddin.xla, and Martha opens the file Fred sent.
If Martha deletes the path, leaving only "=MyUDF()" in the formula, Excel will find MyAddin.xla on Martha's computer in the path where Martha put it (assuming she had previously installed MyAddin.xla as an add-in in Excel), and resolve the formula correctly.
This is one of the many bugbears Excel developers need to face at one time or another, and there are a few work-arounds for it, but which one you choose will depend on your own circumstances:
http://www.jkp-ads.com/articles/FixLinks2UDF00.asp
In case the link dies, here is a summary of the three suggested methods:
Use fixed locations.
Instead of keeping your UDF code inside the addin, you create a facility that copies the UDF routine into each workbook that uses it.
Redirect the UDFs to the new location.
I'm using Excel 2010 and adding a small VBA macro to a spreadsheet. (The purpose of the macro is to take the data on the active sheet and export it to a CSV file, but that's tangential to the question.) The macro determines the output path for the file using ThisWorkbook.Path. I also added a custom button to the Quick Access Toolbar to activate the macro.
After getting a working algorithm in place in my experimental spreadsheet (Test.xlsm, stored in one path), I made a copy of the spreadsheet in another path and renamed it to _Database.xlsm. Then I opened _Database.xlsm and ran the macro. To my surprise, the file was written to the original path, not the new one. And looking down at the Windows toolbar, I saw that Excel had opened the original file over in its original path as well.
After a lot of jiggering around with code tweaks, checking properties and such I finally found that I could prevent this by opening the copied spreadsheet, removing the Quick Access Toolbar button, re-adding it, and then saving the file. My questions are:
Why isn't the macro "independently portable" along with the spreadsheet? I.e. why does the copy maintain this kind of tie to the original sheet?
Is there a way I can create or modify the macro to make it portable in that sense?
If you want a toolbar/button to travel with a file (ie. not always link back to the original version) then you need to add it to the file itself, not to the QAT. The QAT only "knows" about the actual file you linked the button to.
It might be better to add the macro to your Personal Macro Workbook and then just have it operate on the ActiveWorkbook.
However, if you want to distribute it to other users, you can keep the macro in the "database" workbook and add a custom ribbon part. See: http://www.rondebruin.nl/win/s2/win001.htm
I have a workbook, which creates a second workbook (using ThisWorkbook.SaveCopyAs) to present the data nicely to users. It relies on macros for part of the processing.
However, I've been asked to make those macros inaccessible to users. They still need to run them, but to view/edit them should require a password. I can figure out how to do it using the GUI (VBA Editor -> right click VBAProject -> VBAProject Properties -> Protection, tick the box and enter a password), but I haven't found a way to do so using VBA. The Workbook.Protect function seems to lock down everything except VBA.
If I try to apply it to the source workbook, I get "Can't perform operation since the project is protected", so that doesn't work either.
I'm running 2010, but the workbook needs to be compatible with 2003, so no fancy new tricks. :(
This is a method that describes setting the project password without using sendkeys http://www.standards.com/Office/SetVBAProjectPassword.html
This post may be helpful to you. Note that in the comments it says you need to add vbeext1.olb.
I had a similar problem. I needed excel code to populate user created new sheets, but I wanted to password protect the project. It would work great as long as I did not use password proection, but Excel will not allow it to generate code in the new sheets with password protection.
The solution was interesting. Give your project an easy name or initials . Something people can find with ease.
You password protect your entire project and save the resulting file as an XLA (add on).
Then UNprotect the workbook, rename the file (just in case you make a mistake) and strip it of all the code, modules, classes, forms, etc. Save the new stripped Excel File.
Now open the new stripped file and add the xla in TOOLS/add ons. Then go to the VBA editor, References and find your project wiht a new name, and link (you may have to save and reopen once to find under referneces).
That's it. the new file, empty of all code, will operate using the old code but you will have no access to it without a password. At the same time, the old code can place the code on the new worksheets as before since the new workbook Project is not password protected
What I have found is that if you change locations, your users may need to find the link in the references, but I am sure you can create a macro to find and link automatically (that macro, of course, would be visible to the world).
I think this will solve any problem with protected code.
Good luck