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).
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!
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.
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.
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.