XLAM / XLA Addins: is there a better way? - vba

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.

Related

Running functions from Excel Add-Ins in vba, is there an easier way than using Run "mySub"?

I'm trying to create my first Excel Add-In for Excel 2010. Most of it is working, it's running from the ribbon buttons, but I'm having trouble addressing the Add-In's subroutines from my workbook's VBA code.
According to this answer on SO, it should be possible to simply use the syntax:
mySub
or
Call mySub
But this causes the error "Sub or Function not defined". I've only managed to run them this way:
Run "mySub"
or
Application.Run("myAddIn.xlam!mySub")
Is there a way to include the Add-In so I can address it the easy way?
The Add-In is already checked in the Tools->Add-Ins list, and has a unique name (CalcFunctions) which is different from its file name (CalculationFunctions.xlam). The Add-In file is on a different disk and I'm working on a server, but I don't expect that that matters.
(Posted on behalf of the OP).
Turns out I'm just dumb. I only set a reference to the Add-In in the regular Excel window. I assumed that was what people meant by Tools->References->Add-Ins (I use Excel in Dutch and there's no "Tools" menu). Anyway, the solution was setting a reference in that menu in the VBA editor window.
Here's how to add a reference in VBA:
ThisWorkbook.VBProject.References.AddFromFile refPath
With refPath being the full path to the file.
To be able to add references you need to have permission to edit the VBA project. You can enable this in excel settings->trust center->macro settings. If you're on a company pc it's likely the administrator has to set these settings for you.

Normal.dotm equivalent in Excel for referencing the same single VBA code

Just curiosity.
The only way I know so far is to create an add-in with code, put it in some trusted directory and hope it opens when you need it. The drawback is that it sometimes does not open together with application (e.g. I have a custom UDF in the add-in, I use it in the worksheet and an error is what I get, because the addin hasn't started). For this I have a button on my ribbon which calls a sub in the addin which does nothing, but then the addin is activated the UDF works.
Is there any other efficient way to reference code in another workbooks, like in Word we have normal.dotm template?
Indeed, Excel DOES have a common code file, similar in concept to Word's normal.dotm. It is called Personal.xlsb. I use it myself for common functions that I need for several linked yet independent spreadsheets.
Using Personal.xlsb has some disadvantages too, so you'll have to decide if that works better than the Add-in approach. Note that Personal.xlsb works best when its just one person needing common functions across spreadsheets; its not well suited for multi-user access to the spreadsheets in an enterprise environment.
Some useful links are below to get started. Also just google search "excel Personal.xlsb" and you will find a lot more information:
http://www.rondebruin.nl/win/personal.htm
http://chandoo.org/wp/2013/11/18/using-personal-macro-workbook/
To create an equalevant to normal.dot in Excel do this (at least ver. 2016):
Record a macro from the Developer tab (you likely have to enable this tab first)
This will create the file %appdata%\Microsoft\Excel\XLSTART\PERSONAL.XLSB which is Excel's equalevant to normal.dot
Now unhide the hidden workbook called "PERSONAL.XLSB"
Press Alt+F8 or Alt+F11 to edit the VBA code
Extra: VBA example for SaveAs:
Application.Dialogs(xlDialogSaveAs).Show

How to open add-in automatically on opening excel workbook

I want to know how I can have a workbook automatically open an add-in? The problem is after I create the workbook in code -- call it "A.xlsx" -- I want to add code to it (on creation) that will open the Excel add-in "B.xlam". How do I do this? Creating the workbook is no problem; that part is sorted, and I just want to add the code to that workbook, so that every time it opens it must open the add-in "B.xlam" with it.
From the Developer Ribbon, click Add-Ins,
then click Browse, then navigate to the location of the desired add-in file, then select it, and make sure the checkbox is selected for it.
Alternatively, store the code in PERSONAL.XLS/PERSONAL.XLSB, and these macros/functions will be available to all open workbooks.
If you're somehow asking how to programmatically insert code in to new workbook files, I'm afraid you're out of your element. If you don't know about the Workbook_Open event, nor how to manage your Add-Ins, etc., manipulating the VBE is a pretty high-level operation, and I would not be able to help you with that.
Update from comments
Here is one method that will export VB Components to a specific path, example also includes code to import modules from path to a workbook. You should be able to adapt this to your purposes.
http://www.rondebruin.nl/win/s9/win002.htm
If you have specific problems implementing this solution, please post as a new question.

How to check if code that is run belongs to active sheet

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).)

Standalone code for Excel

Can VBA code be written to perform actions on any Excel file?
When I create a project in Visual Studio, it asks for an Excel file to be linked to it. All the code that I write is in ThisWorkbook.vb and hence acts only on the Excel file linked to the project.
Ideally, I want a script that:
When the user double-clicks, he/she should be allowed to select an Excel file of choice for the actions to be performed on that file.
If the above is not possible, I'd at least like to invoke the VBA script from within an Excel file.
Basically, the VBA code should be independent of any Excel file.
I looked at VBScript, but the syntax for it seems to differ slightly.
You've mentioned Visual Studio, VBA, and VBScript. The solution I'm outlining works directly with VBA rather than Visual Studio or VBScript. (However, you might adapt Visual Studio (C# or VB) along the lines of what I'm outlining below.) Hope it's helpful, so here goes:
Here's what I do, and, it ultimately results in an .xlam Excel AddIn as #chris above has commented.
Overview
I start with ordinary .xslx workbook, to which I add a VBA project, making it an .xlsm. Then create some VBA Subs (macros). Then create some Excel QAT (Quick Access Toolbar) buttons for the workbook, which are bound to (i.e. they invoke) the VBA subs/macros. Then convert the workbook (with VBA in it) to an .xlam, which is an Excel AddIn. When you're all done, the buttons are accessible from any workbook (and the VBA code has access to any user workbooks as well as those originally in your .xlsm). Further, the workbook associated with the .xlam is invisible. So it just looks like you've added some buttons to the QAT that appear on all users .xlsx windows. The .xlam is pretty easy for users to install (though I provide a buttons to uninstall/reinstall/check version). You can upgrade an .xlam independently of users' workbooks; users' workbooks can thus be data only (.xlsx, no VBA).
Details
Write some Excel Subs you want to use later
You need to be aware that the buttons can only invoke macros (VBA Subs) without parameters, so the macros will have to check things like ActiveSheet and ActiveWorkbook and Selection to figure on what sheet the button was pressed, hence what user data to really operate on. (If you need to refer to your workbook with the VBA code in it, use “ThisWorkbook”). You should be aware that there can be naming conflicts, so try to name the parameterless subs with rather long names, such as MySomewhatUniqueProjectName_button1, etc…
Add Buttons to your .xlsm
Using Excel 2010 (I think this works with 2007 or later), I put workbook-specific buttons on the QAT part of the ribbon, which connect to macros (VBA subs) in the VBA code.
To do this, you from the Quick Access Toolbar customization drop down (the tiny down arrow at the very top row of the Excel window, the last icon from left to right) choose "More Commands…". When the “Customize Quick Access Toolbar” dialog box comes up, from the (2nd) "Customize Quick Access Toolbar:" heading (top to the right), choose "For XYZ.xlsm" from the dropdown instead of the "For all documents (default)". And from under "Choose Commands From:", use "Macros" (instead of “Popular Commands”) from the dropdown. Once you have those two things selected, you can move VBA subs from the left box to the right box using “Add >>”. Each so moved will become buttons visible in your QAT. As you’re doing this you can also edit the icon and text for the buttons, add a separator as needed (I always end with a separator in case other .xlam’s use the QAT). (Now is a good time to save this .xlsm.)
Convert the .xlsm into a .xlam
Then I convert the .xlsm to an Excel add-in, by merely saving it as an .xlam file. This will end up (1) hiding the workbook associated with the code you have (though it is still accessible to itself.). Further, now, (2) the (invisible, as now it's an .xlam) workbook will load whenever Excel is loaded. (To keep this fast for when users use Excel but don’t run my VBA code, I don't run any code when the .xlam is loaded, I only run code when a button is pushed.)
You can manage the AddIn using Excel’s AddIn manager. To update the AddIn, you have to use some trickery. While you can copy over it when Excel is not running, on the other hand, you cannot directly uninstall the AddIn, you can only disable it from Excel. But once disabled, you can delete the .xlam, and relaunch Excel, go to the AddIn manager to try to work with the (now gone) AddIn and you’ll get Excel saying it can’t find it, so do you want to delete it. Say yes, and it will be uninstalled.
FYI, Notes
I keep the .xlsm to edit later, but you can actually debug and edit the .xlam and later convert it back to an .xlsm with a minor bit of trickery: find its "ThisWorkbook" entry in VBA, and then the "IsAddIn" property, set to false, its workbook will suddenly appear and you can save as .xlsm, or edit its workbook and set the property back to true to resave as .xlam directly.)
Answer 1
You can do that in VB.Net too. Just make a regular project. (comment by #SLaks)
This worked for me very well and was exactly what I was looking for.
Answer 2
The very descriptive answer posted by #ErikEidt
I haven't tried this, but it seems like a good and alternative way of getting macros to work.