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.
Related
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 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.
"The Business" wrote a sophisticated Excel VBA Macro that scans multiple complex and irregular (multiple logical tables per tab) spreadsheets and produces a summary XLS. Management wants IT to "productionize it" and run it on a server.
I've seen example of using the Jet drive to read regular tables (1 per tab) in a spreadsheet, but the spreadsheets are irregular and this macro does more than read, it sets cell formulas, etc. Therefore, I guess we need full VBA.
How do you do this in production if you can't install Excel on a production server?
You can use a library for interacting with Excel files like Spreadsheet Gear for instance... I am sure there are plenty of others. You can then read the Excel files and then produce the summary XLS. You'd need to tie it all together using VB. You wouldn't need to install Excel on the production server though.
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.
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.