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.
Related
I have been working on an experimental clinical data analysis tool in Excel using VBA userforms for the data entry UI. Because there are more than 100 unique userforms (and growing) it has become necessary to build the UI screens programmatically at runtime to avoid the VBA environment in Excel freezing when more than +/- 40 userforms are stored. I have been helped greatly at Stack Overflow to help programmatically build the userforms.
Recently I discovered Power Apps forms. It looks better than VBA userforms, has built in SQL functionality, but more importantly the forms will exist outside of Excel's finicky VBA environment. There is almost no online information out there about the integration of Power Apps in Excel. I need to remain using Excel spreadsheet to crunch the data because it is the comfortable and familiar sandbox for me to play in.
So my question, is integration of MS Power App Forms into Excel a viable alternative to replace native VBA userform functionality in Excel? I want to know ahead of time to avoid entering a time consuming rabbit hole just to discover it is not actually viable.
It looks like the best answer to my question is a non-answer. After several weeks no one has provided input as to how the integration of MS Power Apps forms into Excel can best can be achieved. It is likely not a feasible alternative to VBA userforms at this time (early 2023).
I am new to VBA and I am trying to determine when to use the Excel Personal Macro Workbook Vs Excel Add-Ins. I am using Office 365 Subscription (up to date) on a single Win10Pro PC.
My understanding is that if one wanted to write a Sub or Function once, and yet have access to it in all open workbooks on the same machine (which is fine for my code), then one could either place the code in the Excel Personal Macro Workbook OR create an Excel Add-In.
Some sites suggest this is simply a matter of preference. Is that indeed the consensus or is there a general set of guidelines for deciding when to utilize one method over the other?
When I tried to insert a new sheet, I was given multiple options which I could choose from. One is obviously "Worksheet", another is called "MS Excel 4.0 Macro". So I chose "MS Excel 4.0 Macro", and it looks exactly the same as a new worksheet. I'm just curious what is the difference between a regular worksheet and MS Excel 4.0 Macro sheet?
History
From its first version Excel supported end-user programming of macros (automation of repetitive tasks) and user-defined functions (extension of Excel's built-in function library). In early versions of Excel, these programs were written in a macro language whose statements had formula syntax and resided in the cells of special-purpose macro sheets (stored with file extension .XLM in Windows.) XLM was the default macro language for Excel through Excel 4.0. Beginning with version 5.0 Excel recorded macros in VBA by default but with version 5.0 XLM recording was still allowed as an option. After version 5.0 that option was discontinued. All versions of Excel, including Excel 2010 are capable of running an XLM macro, though Microsoft discourages their use.
https://en.wikipedia.org/wiki/Microsoft_Excel
The purpose of MS Excel 4.0 Macro sheets is to run legacy Excel 4.0 macros. Microsoft replaced Excel 4.0 Macros with VBA in 1993, but they can still be run. Now (almost 30 years later), this is most extensively used by malicious parties (hackers).
For example, you can enter the following into A1:A2:
=EXEC("calc.exe")
=HALT()
Then, to run it (to open the Calculator) you would need to right click A1 and choose Run... -> Run. All the formulas downwards from the clicked cell will be evaluated.
PDF containing the complete Excel 4.0 macro functions reference
Answer.
The old way was to record a macro as a chain of events, without VBA.
My story.
I made heavy use of old-style macros and I have had hundreds of them. When Microsoft shifted macros to VBA they offered no way to convert the old ones, and so I lost all of them at a glance. One of my macros was highly complex and ran like a dream on Mac SE. I regarded it as highly precious in scientific value as it worked using Tritium observations in ground-water aquifers with a huge input function data sheet. It calculated the residence time of ground-water using several mathematical models as well as updating five charts that plotted the output data using introduced by the user for the used models. I saved this macro file to a Windows PC using a complex procedure via the EMU emulations hardware, a modern Mac, and a modern Windows PC, however the file will not run as it was written before the introduction of VBA. It is such a sad loss, and would go as far as considering the loss as criminal.
Please don't delete this story until I have backed it up somewhere. When I have posted it somewhere more appropriate, I promise to delete it.
I am wondering if it is possible to let an HTML/JS add-in open and close a set of workbooks one by one.
I have not seen the JavaScript API to open or close a workbook, and don't know if it is doable in a JavaScript function.
Otherwise, because VBA can repeat opening and closing workbooks, is it possible to set a mechanism in VBA to run systematically a function of an HTML/JS add-in every time a workbook is open?
There is no built-in functionality for this in the JS APIs. We are aware of the gap, and it is on the long-term roadmap, but not something on the immediate horizon.
Depending on whether the workbook being opened already has your Office Add-in inserted or not, though, you can probably do a VBA workaround. Namely, you could have the Office Add-in create a binding (if it's not already there) on some well-known cell in a hidden sheet, and attach an event listener to it. VBA would then go and write in to the same cell, triggering the event. Again, this only works if the add-in is already inserted and essentially in a template-like scenario; but if it fits your requirements, then that would work.
Best!
~ Michael Zlatkovsky, developer on Office Extensibility team, MSFT
A friend of mine has a very complex Excel spreadsheet with many formulas and lots of data that he uses for work. He wants to put a custom GUI on top of it and then wants to sell it to other people in his profession. Basically he wants to make some freestanding software out of his spreadsheet? Is there any way to put a custom GUI on top of an Excel spread sheet? The spreadsheet would just reside in the backend and be a kind of database and do the calculations necessary. I know this is definitely not an elegant solution but I told him I'd look into it. Any ideas?
I use Clear Office.
You can host workbooks in your GUI, host GUI in your workbook. All .NET, no interop.
Excel Interop fits the bill. Code your GUI with WinForms/WPF and .NET; invoke excel in the background to be your calculation engine. Pretty ugly (and probably slow) solution, though.
Check out the book Professional Excel Development by Bovey. It talks about how to do some radical Excel customizations along the lines of what you are suggesting.
Depending on how complex the application/input is, he may be able to use userforms, which are built in to Excel. Alternately, he can set up a sheet as in input form, and use other sheets for data/calculations, and super-hide them. We made a spreadsheet for a company at work, and used both solutions. Userforms can be frustratingly inflexible, but they work.
You can also add in some VBA to show the Userform when the workbook is opened, although if macros are disabled (which they are by default) then it won't work.