Build an add-in and UDF for all the Excel versions - excel

One data provider wants to develop an Excel add-in, these are the requirements:
1) it can be installed on desktop. It adds one menu and buttons in Ribbon, and it also provides some specific functions (to get real-time data, like Bloomberg function).
2) the add-in should work in Excel 2007, 2010, 2013 and 2016.
The question is which technology should be used to create this add-in. Here are some of my thoughts:
1) JavaScript API for Excel does not fit, because it does not work for Excel 2007, 2010.
2) VSTO. Does anyone know if VSTO add-ins work for Excel 2013 and 2016?; Is it possible to build one VSTO add-in that works for all Excel 2007, 2010, 2013 and 2016?
3) C API for Excel. It seems that C API for Excel is used to build XLLs. Does anyone know if C API for Excel can build menu and buttons?

Here are some points :
JavaScript API , they are web based addin, so your add-in won't work without internet but it seems that your solution is for a data provider so I assume your clients will have internet. As you said, it didn't work for pre 2013 versions. see here
VSTO, probably the best option but you need to be aware of a major change related to MDI/SDI between Excel 2013 and previous version. Others small tweaks may appear (image idmso, some events..) but VSTO 2007 should be 2016 compatible. VSTO 2016 doesn't exist, the latest release is 2010 (Version 4.0 Runtime). You should test it regularly during development time to check the compatibility.
It is possible to add a menu (a dropdown list) and a toolbar via the Excel C Api (using xlfAddMenu and xlfAddToolbar) but not ribbon controls that require the COM Interface IRibbonExtensibility. So the only way to add controls to the rubbon is via the COM technology (from wich VSTO is based on). The Excel C API didn't change since the 2007 version so it will be fully compatible for all versions. You can find a working example in the Excel C API 2010 SDK (not in the 2013 SDK -this part has been removed), in the file GENERIC.C , see the xlAutoOpen function. Also please note that it is very difficult to find information about it.
From my point of view, you have two possibilities: 1) implement everything via VSTO or 2) to implement your routines via the Excel C API and to interact with it via a VSTO addin that is just used for ribbon controls. I would suggest you the first solution (VSTO), you'll find more documentation about it.
EDIT :
Just realized your question is also about UDF. There are three ways to add UDFs to Excel : via VBA, via a COM automation and via the Excel C API. The best option for UDF is definitively the EXCEL C API but there exist an open source project that "wrap" this API in C#, see Excel DNA.
EDIT 2 :
As an alternative to VSTO, still in Net, there is the NetOffice project on Codeplex that it is worth trying it, they claim that they support all Excel versions. It won't help you regarding the UDFs part but for the GUI it seems to be a good candidate.

Related

How to prevent Excel 2013 custom ribbon buttons from disappearing

I am working with Excel 2013. I've written several macros in Personal Workbook modules. I've created custom buttons in the ribbon to run those macros and everything works fine. Next day I run Excel and the custom buttons are gone. I tried this many times and the result is always the same. Strange thing is that custom buttons that I have created more than a year ago are there and are never removed
I have done some research and it seems that Excel does this for security issues. Is there a way to bypass this button deletion?
VBA macros is not designed for customizing the Ribbon UI (aka Fluent UI) in Office applications. For current document you may include a custom ribbon UI into the document. For example, the following articles describe how to do that for Word documents, but the approach is common for Excel and Word documents:
OfficeTalk: Customizing the Word 2007 Fluent Ribbon is as Easy as 1-2-3 (Part 2 of 2)
OfficeTalk: Customizing the Word 2007 Fluent Ribbon is as Easy as 1-2-3 (Part 2 of 2)
If you need to distribute your customizations on multiple machines, I'd suggest developing a COM add-in instead, for example, it can be a VSTO add-in. That's what they were invented for. Moreover, you can create a custom UI customizations as a part of the add-in.
Read more about the Fluent UI in the following series of articles:
Customizing the 2007 Office Fluent Ribbon for Developers (Part 1 of 3)
Customizing the 2007 Office Fluent Ribbon for Developers (Part 2 of 3)
Customizing the 2007 Office Fluent Ribbon for Developers (Part 3 of 3)
If you customized the ribbon using file->options, you can see the .officeui file in the below folder, I think this file is not synchronized in your next login, but you can copy to your local, and when it's missing you can copy that officeui file to the %appdata% directory as mentioned below.
%appdata%/Microsoft/office
I recommend you to customize the ribbon in your workbook using CustomUI editor, so that it will retain the customization inside your workbook and not as the separate file (OFFICEUI).

Package a Ribbon with a Custom VBA Add In for Microsoft Office

I am working with Excel 2010 but I assume the idea is constant accross all of Office 2010.
I am making an Add in to have some VBA Macros that will work with all of my files and would like to make a ribbon that has buttons bound to these macros. I know how to make a ribbon through Excel Options --> Customize Ribbon but I would like to make one that is shown whenever the Add In is active. This is so I can distribute the Add in with an easy way to run the macros.
Is there a way I can do this? Thanks
UPDATE:
I have read into it and with what I have at my disposal here (Office 2010 and notepad) I am going to have to make the ribbon as an XML document and then put that with my xlam file. I am just not sure on the specifics at this point.
I suppose you are developing a VSTO based add-in. If so, you have two ways to go:
VSTO provides a Ribbon designer which you can use to build the custom UI. See Walkthrough: Creating a Custom Tab by Using the Ribbon Designer to get started quickly.
The other way is to use the Ribbon XML markup for buidling a custom UI (available for all kind of add-ins). See Walkthrough: Creating a Custom Tab by Using the Ribbon Designer for more information.
In general, the Fluent UI ( aka Ribbon UI) is described in the following series of articles in MSDN:
Customizing the 2007 Office Fluent Ribbon for Developers (Part 1 of 3)
Customizing the 2007 Office Fluent Ribbon for Developers (Part 2 of 3)
Customizing the 2007 Office Fluent Ribbon for Developers (Part 3 of 3)
I ended up doing it by hand based on this answer.
Worked well, just a little tricky working with zipping the Excel Files. Never Unzip the entinre file, just open it with explorer and copy files into it and it worked well!

how to use a macro in excel

The question is there are 'n' different ppts and I want to put all the ppts in one single ppt. Condition is I should not use copy paste rather I should write a function in excel using macros to get it done. So how do I do this?
It looks like you need to automate PowerPoint from Excel. The How to automate PowerPoint by using Visual Basic in Office 2003, in Office XP Developer, and in Office 2000 Developer article describes all the required steps for getting the job done. Be aware, the reference number corresponds to the Office installed on your machine. For example:
Microsoft PowerPoint 15.0 Object Library
Stands for PowerPoint 2013 and etc.

ADOMD & Excel Integration

All,
We have an Excel spreadsheet that uses ADOMD to query OLAP cubes and present the data in Excel. We are using version 2.8 at the moment of the ADOMD API. As far as I know there is an ADOMD.NET API for querying OLAP cubes. Can this new .NET version used from inside Excel ?
Many Thanks,
MK
ADOMD.NET can only be called from .NET code which means that you can't use it inside a VBA macro. You will have to create an Excel project in Visual Studio and write your code in the .NET language of your choice. There are 3 types of Excel projects in VS2010, Excel Document, Excel Template and Excel Addin.

Excel programming methodologies

What are the differences in Excel programming between a UDF, Macro, Add-in, Automation Add-in, XLL, or VSTO.
Which one I should use and under which circumstances?
I'll try to group/oppose some of the elements you mention:
VSTO vs. VBA:
VBA (visual basic for applications) is the "classic" way to write Office automation. Excel has a development interface which you can fire from office to write macros and UDFs, and which hasn't changed for about 10 years. On the plus side, deployment is trivial, and VBA offers nice features like macro recording, which record your actions into code, and provide a good way to figure out the object model.
VSTO came about more recently, and allows you to automate office using .NET (uses COM). You can leverage all .NET and Visual Studio (ex: add WPF forms), which gives great flexibility but the deployment is more complex.
UDF vs. Macro vs. Add-In
User defined functions are custom-made methods which will stay attached to your workbook; once added gain the same status as the "built-in" Excel functions: you can call them from worksheets like =MyFunction()
Macros are procedures which will stay attached to your workbook. They can be called directly by the user, or attached to events (ex: when a worksheet is selected, do this).
Add-ins are not attached to a specific document, but to the application itself. Typically a macro or UDF is attached to the workbook: when you open the document, the code becomes available to you, and when you give the document, the code is copied as well. By contrast, Add-Ins are attached to the application: the moment you launch Excel, the add-in becomes available to you. Tools like the Solver are an Add-in. Note that Add-Ins can be written in either VBA or using VSTO (you can also write UDFs in .NET, but it's atypical).
When to use what
Add-In vs Macro/UDFs: write an add-in if your functionality should be accessible from any workbook.
VSTO or no VSTO: this is a matter of debate. Most people who are familiar with "classic" VBA automation don't like VSTO too much, because the learning curve is a bit steep. If you are used to working with .Net, this should not be a bit issue - but VSTO is somewhat quirky compared to "normal" .Net apps development.
Note also that if you use VSTO, your code can't be edited by the user. This is arguably desirable, but at the same time, Excel power-users usually know how to use VBA and macros, and expect to be able to tweak the code. That can lead to interesting discussions.
Personally, I typically use VSTO for add-ins, and I use it as soon as I see that lots of logic / procedural code is going into macros in VBA. What VSTO gives me is the ability to write testable code, in Visual Studio, and also high-performance code when heavy calculation is involved. The other reason to use VSTO is to leverage WPF to customize office.
Use VBA for Excel 2003 and earlier (though you could still use it in 2007 if you want).
VSTO is for Excel 2003 or 2007.
The old Excel 4.0 macro language should definitely not be used anymore, they keep disabling parts and the functionality is disappearing. We're having to rewrite all our spreadsheets to get the old macros out.
Macros are also another name for VBA code.
An Add-in is just another Excel workbook that has code in it (like VBA), so that you can use the code in different books, and keep the code directly out of the users book.
An UDF is just a function written in VBA that get's called as a worksheet function in a cell in a spreadsheet (it can also be stored in an Add-in).
Lance has good definitions to your questions. In terms of what to use when, VBA vs VSTO--if you are needing to use .net framework go with VSTO. For instance is I wanted to make a VB.net program interface with a spreadsheet learning VSTO would be the way to go (that and vba does not have an array.sort like vb.net which drives me crazy). However if you are making a nifty spreadsheet that will do some cool things for your end users (formulas, charts etc) just whip up some VBA code within the spreadsheet. It all depends on what you have to do. Best tool for the job.
A few more points from the VBA side of things:
Add-in - All of your non-trivial code should go in an add-in. A typical project for me consists of an add-in that contains all of the code, a data store (database, text file, Excel workbook) to hold the data, and one or more templates as presentation layer or user interface. You don't have to use an add-in; code will work just fine in modules within your templates. However, it's a good practice to keep your project layers separate. Code goes in an add-in, data goes in a data store, presentation pieces go in a workbook or workbooks. This way, you can change your code without affecting the other two layers. Or you can change a presentation template without affecting the existing data.
UDF - This is declared with the Function keyword. Use a function if you need to return a single value (or array or object instance etc). Custom worksheet functions are UDFs because they only return a value to a cell. They don't change any properties of the cell except the Value property. You can't apply borders or fonts, for example, via a function.
Macro - Also called a procedure, they are declared with the Sub keyword. Use a procedure if you need to do something other than return a value, such as if you need to manipulate parts of the Excel object model.

Resources