I had a VB script function Sub Workbook_Open() that was copying a value from one cell (a total from previous day) to another cell at file opening. Now I would like to put my Excel sheet online (MS Excel Online) where execution of VB scripts is not supported so I am trying to realise the same functionality with a formula like =FUNCTION().
Is it possible and how to evaluate a formula only once each time at file opening in MS Excel Online (without using VB script)?
While you cannot use VBA in Excel Online, you may be able to use Office Scripts.
This new scripting technology is currently in preview and it also needs to be enabled by your tenant administrator.
https://learn.microsoft.com/en-us/office/dev/scripts/overview/excel
If you don't yet have access to Office Scripts, I'm afraid there is no solution for what you describe.
Unfortunately the Online MS Office Scripting is not yet a reality as you can see on this link. Hopefully Microsoft have mercy on us one day and allow us to have this crucial feature for some of our most important workbooks. In the meantime, we shall be using this feature only offline.
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
My understanding is that when I create a workbook VSTO solution, I need to register (implicitly or explicitly) the solution in the registry. When developing the VS takes care of this.
If I wanted to have more than physical xlsx files with different names and reuse the VSTO code what to do?
A simple copy/paste of the workbook file won't work of course. I don't want to register each new workbook in windows registry since this could be a serious hassle.
Typical case would be: Say a user collects monthly data in workbook xlsx file. You need to run the VSTO code in each workbook xlsx file separately. As a result you end up having 12 sheets per year. Using VBA, you could easily copy the files and change the names - How to do the same when VSTO is used?
I thought of using a template but I wanted to ask before I waste time on it.
I am using VS2010, C#, Excel 2007.
I have a reasonably complex macro that I need to run on multiple different excel sheets, this macro is updated periodically and whenever a change is made its necessary to change it in each individual excel sheet. is there a way to get each excel document to refer to the one macro?
for example if i had a hierarchy like this:
DOCUMENTS:
-xlsheet1.xls
-xlsheet3.xls
-xlsheet2.xls
MACROS:
-macro1.bas
where there was a button in each sheet that ran macro1 when clicked.
I would recommend either moving that macro to your personal file or create an Add-In
Working with Personal File
Topic: Create and save all your macros in a single workbook
Link: https://support.microsoft.com/en-us/office/create-and-save-all-your-macros-in-a-single-workbook-66c97ab3-11c2-44db-b021-ae005a9bc790
Quote from the above link:
When you first create a macro in a workbook, it works only in that workbook. But what if you want to use the macro in other workbooks? To make your macros available every time you open Excel, you can create them in a workbook called Personal.xlsb. That’s a hidden workbook stored on your computer, which opens in the background every time you open Excel.
Creating an Add-In
Topic: Creating Excel Add-ins
Link: http://www.ozgrid.com/VBA/excel-add-in-create.htm
Quote from the above link:
I am often asked by users 'what is the best way to distribute their macros?' My answer, is without doubt via an Excel Add-in. After all, this is what Add-ins are for. For those that are not sure what an Excel add-in is, it's is nothing more than an Excel Workbook that has been saved as an Add-in, File>Save as \ Microsoft Excel Add-in (*.xla). Once saved and re-opened the Workbook will be hidden and can only be seen in the "Project Explorer" via the Visual Basic Editor. It is NOT hidden in the same way as the Personal.xls as this can be seen (and made visible) via Windows>Unhide.
The Personal file is good for having a macro across any number of workbooks on a single computer. In a networked environment with multiple users, you could simulate the Personal file by having a single workbook with your macros in it and coding all other workbooks to open and hide this workbook when they start up.
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.