I own Mac computer products and I use Office 365 for Mac/online. Eight years ago, I designed an Excel macro with vba userform (calculates personal financial stuff). I need to update the macro annually but haven't been able to redesign the userform. Questions...
Has anyone figured out how to redesign the userform within Excel for Mac without having to use a virtual machine/Windows? I would hate to pay for a vm/Windows annually just for one macro update.
I've noticed MS 365 does not allow any macros to run on the web versions. Have you all abandoned ship and gone a different route (ex: Google Sheets)? I would like my file to be accessible from anywhere.
Any helpful advice would be appreciated.
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 have a report that I run from a system once a week, and the data is exported into an excel document. I have set up the tool that exports the data to excel to do a decent job on formatting, but there is still more that I need to do once the data is in excel.
Is it possible to create a stand alone macro, save it in a Microsoft office folder and be able to call it after I open this file? I have written plenty of macros that are part of ONE given spreadsheet, but never tried one that was open to many spreadsheets.
IS it possible, and a starting direction of good resources of where I can learn how to achieve this goal? Thank you.
...and be able to call it after I open this file?...
You have 2 very good options
1) Write and save your macro to Personal file. See this link for more information
Topic: Deploy your Excel macros from a central file
Link: http://office.microsoft.com/en-us/excel-help/deploy-your-excel-macros-from-a-central-file-HA001087296.aspx
Quote from the above link:
Have you ever wanted to use that really handy macro in all of your Excel worksheets? You can. This column explains how to place your macros in a file called personal.xls and make them available each time you start Excel.
2) Create an Add-In
Topic: Creating an Excel Add-in
Link: http://msdn.microsoft.com/en-us/library/aa140936%28v=office.10%29.aspx
Quote from the above link:
You create a Microsoft® Excel add-in by creating a workbook, adding code and custom toolbars and menu items to it, and saving it as an Excel add-in file.
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.