My colleagues and I have created a userform with a suite of tools for doing tasks in Excel and Word
I'm quite familiar with spawning application objects from modules and closing them without effecting anything else - or other running copies of Excel.
However the user form must start some where - this leaves an Excel sheet open in the background.
I have tried Application.Visible = False but this hides all open workbooks - Kind of annoying if you have other worksheets open
I was thinking of a wrapper sheet which creates an Excel and runs the macro (spawning the macro in its own instance of Excel) - this works but then Im left with the wrapper sheet and potentially an orphan excel app if I close my parent.
Is there a better way than this to execute macros without affecting the rest of the user experience on MS office?
Yes, you can create an Excel add-in. Simply save the Workbook containing your code as an Excel add-in (select the appropriate file format in the "Save As" dialog) and configure Excel to load the add-in at startup in the "Options". You won't see anything of the add-in besides the functionality it provides.
Related
We have a spreadsheet with some VBA in it that compiles data from multiple tabs to generate a score and pull over comments.
I am the only user who cannot run the macro. When I try to run the macro, either via the macro button or directly from the macro window, nothing happens. This issue is specific to this single file, as I'm working all the time with macro-enabled workbooks. So the problem isn't tied to my Trust Center settings.
My only smoking gun is that most of the code sits in the "ThisWorkbook" Excel Object. If I try to move some of the code to a module, then I can run it, although I get an error since the code was designed to sit in ThisWorkbook.
Any idea why I would be the only person who can't run this macro? Also, I've disabled all add-ins, so I don't think that's the issue.
I built an Excel workbook at a customer site, on their hardware, using Excel 2010. The workbook has an ActiveX button to execute macros to run a SQL stored procedure and populate a data sheet. I use the same code at all my customers. The workbook runs fine. I password protect the VBA to stop anyone changing the code.
I took my usual backup copies. When I open the workbook on my laptop, running Excel 2016, I get the
"we found a problem with some content..."
recovery message. If I recover, it removes the button and some of the VBA code.
I have tried amending my Trust Centre settings but no difference. When I VPN into the client, the workbook onsite opens OK. However, another external party has tried opening one of the workbooks using his local 2013 version and gets the same thing.
Apparently, the CFO uses Excel for Mac so I am wondering if this is causing an issue, or whether there is something screwy going on with the versions of Excel. I have created at least 12 workbooks, all using the same code, and they all behave in the same way.
Any suggestions would be greatly appreciated.
after advice from Dave yesterday, it appears that replacing my ActiveX Control with a Form Control has done the trick. I had to amend my macro code slightly as there is no onclick option for a Form button so I created a sub that calls my various VBA chunks which is then assigned to the button.
Thanks for all the responses and advice.
Can VBA code be written to perform actions on any Excel file?
When I create a project in Visual Studio, it asks for an Excel file to be linked to it. All the code that I write is in ThisWorkbook.vb and hence acts only on the Excel file linked to the project.
Ideally, I want a script that:
When the user double-clicks, he/she should be allowed to select an Excel file of choice for the actions to be performed on that file.
If the above is not possible, I'd at least like to invoke the VBA script from within an Excel file.
Basically, the VBA code should be independent of any Excel file.
I looked at VBScript, but the syntax for it seems to differ slightly.
You've mentioned Visual Studio, VBA, and VBScript. The solution I'm outlining works directly with VBA rather than Visual Studio or VBScript. (However, you might adapt Visual Studio (C# or VB) along the lines of what I'm outlining below.) Hope it's helpful, so here goes:
Here's what I do, and, it ultimately results in an .xlam Excel AddIn as #chris above has commented.
Overview
I start with ordinary .xslx workbook, to which I add a VBA project, making it an .xlsm. Then create some VBA Subs (macros). Then create some Excel QAT (Quick Access Toolbar) buttons for the workbook, which are bound to (i.e. they invoke) the VBA subs/macros. Then convert the workbook (with VBA in it) to an .xlam, which is an Excel AddIn. When you're all done, the buttons are accessible from any workbook (and the VBA code has access to any user workbooks as well as those originally in your .xlsm). Further, the workbook associated with the .xlam is invisible. So it just looks like you've added some buttons to the QAT that appear on all users .xlsx windows. The .xlam is pretty easy for users to install (though I provide a buttons to uninstall/reinstall/check version). You can upgrade an .xlam independently of users' workbooks; users' workbooks can thus be data only (.xlsx, no VBA).
Details
Write some Excel Subs you want to use later
You need to be aware that the buttons can only invoke macros (VBA Subs) without parameters, so the macros will have to check things like ActiveSheet and ActiveWorkbook and Selection to figure on what sheet the button was pressed, hence what user data to really operate on. (If you need to refer to your workbook with the VBA code in it, use “ThisWorkbook”). You should be aware that there can be naming conflicts, so try to name the parameterless subs with rather long names, such as MySomewhatUniqueProjectName_button1, etc…
Add Buttons to your .xlsm
Using Excel 2010 (I think this works with 2007 or later), I put workbook-specific buttons on the QAT part of the ribbon, which connect to macros (VBA subs) in the VBA code.
To do this, you from the Quick Access Toolbar customization drop down (the tiny down arrow at the very top row of the Excel window, the last icon from left to right) choose "More Commands…". When the “Customize Quick Access Toolbar” dialog box comes up, from the (2nd) "Customize Quick Access Toolbar:" heading (top to the right), choose "For XYZ.xlsm" from the dropdown instead of the "For all documents (default)". And from under "Choose Commands From:", use "Macros" (instead of “Popular Commands”) from the dropdown. Once you have those two things selected, you can move VBA subs from the left box to the right box using “Add >>”. Each so moved will become buttons visible in your QAT. As you’re doing this you can also edit the icon and text for the buttons, add a separator as needed (I always end with a separator in case other .xlam’s use the QAT). (Now is a good time to save this .xlsm.)
Convert the .xlsm into a .xlam
Then I convert the .xlsm to an Excel add-in, by merely saving it as an .xlam file. This will end up (1) hiding the workbook associated with the code you have (though it is still accessible to itself.). Further, now, (2) the (invisible, as now it's an .xlam) workbook will load whenever Excel is loaded. (To keep this fast for when users use Excel but don’t run my VBA code, I don't run any code when the .xlam is loaded, I only run code when a button is pushed.)
You can manage the AddIn using Excel’s AddIn manager. To update the AddIn, you have to use some trickery. While you can copy over it when Excel is not running, on the other hand, you cannot directly uninstall the AddIn, you can only disable it from Excel. But once disabled, you can delete the .xlam, and relaunch Excel, go to the AddIn manager to try to work with the (now gone) AddIn and you’ll get Excel saying it can’t find it, so do you want to delete it. Say yes, and it will be uninstalled.
FYI, Notes
I keep the .xlsm to edit later, but you can actually debug and edit the .xlam and later convert it back to an .xlsm with a minor bit of trickery: find its "ThisWorkbook" entry in VBA, and then the "IsAddIn" property, set to false, its workbook will suddenly appear and you can save as .xlsm, or edit its workbook and set the property back to true to resave as .xlam directly.)
Answer 1
You can do that in VB.Net too. Just make a regular project. (comment by #SLaks)
This worked for me very well and was exactly what I was looking for.
Answer 2
The very descriptive answer posted by #ErikEidt
I haven't tried this, but it seems like a good and alternative way of getting macros to work.
I have added a toolbar menu for my macro, so I can just press the button and it runs my macro from any excel document. Every time I run the macro though, it opens the source file containing the macro. Is there a way that it won't open the source file and just run the macro? (even opening and closing wouldn't too much of an issue, but I'd prefer not opening it at all)
I haven't been able to find any information about this, so all help to get me started is appreciated.
You can't pull code out of the air to run it; Excel's going to have to open the file the code's stored in to run the code.
If I understand it correctly, you can create an Excel add-in from your code and have the add-in load automatically when Excel starts. Your code will always be available in that case.
This seems like a good place to start:
http://msdn.microsoft.com/en-us/library/aa140990(v=office.10).aspx
USE YOUR PERSONAL MACRO WORKBOOK
Open the VBEditor and find the module containing your macro.
Copy that code.
Now in the VBProject Panel on the left, locate your PERSONAL.XLS or PERSONAL.XLSB project. This is the project where you store macros you want available at all times. Add a module to that project and put your code into it.
Now update your "button" so that it points to the macro in that workbook and you're good to go.
On the off chance your PERSONAL.XLS project does not exist, use the macro recorder to record a "junk" macro and be sure to set it to "Store Macro In: Personal Macro Workbook"... that will create it for you the first time.
This post is about installing XLAM's without creating links. (Everyone hates links). Consider the trivial addin:
Public Function UDF_HELLO(x)
UDF_HELLO = "Hello " & x
End Function
Put this code and nothing else into a Module and save as "Hello.xlam" on the Desktop (and NOT in the default excel addins folder). Next, while HELLO.XLAM is still open, create a new XLSX workbook with the formula
=UDF_Hello("world")
in cell A1, which simply displays "Hello world" in that cell. Save the workbook and exit Excel. Now, if you reopen the workbook without the XLAM, Excel will complain about "links to other sources ...". Whether you click "Update" or "Don't Update", Excel will mangle the formula in cell A1 like this:
='C:\Documents and Settings\tpascale\Desktop\Hello.xlam'!UDF_Hello("world")
Very often this "forced-linkage" is NOT desirable. In my computing environment there is a lot of ad-hoc analysis and it makes no sense to impose an install regimen on every XLAM we throw together to solve the problem of the day. I just want to hand out XLAM files to users and let those users open them when they need them, WITHOUT having to worry about the slightest mis-step causing their formulas to get mangled.
QUESTION:
Is there a way to instruct Excel to NEVER construct external links for UDFs, and simply to use UDFs if they're loaded and return #VALUEs otherwise ?
I don't know of a way around this with .xla/.xlam add-ins.
But this issue does not occur with .xll add-ins.
These can be created in C using the Excel 2010 SDK, or in managed languages like VB.NET or C# using the free Excel-DNA library.
(Disclaimer: I'm the developer of Excel-DNA. This issue is one of the reasons I went with the .xll interface for making managed UDF add-ins.)
You can have them open the .xla file and have an Auto_Open procedure install the add-in.
http://www.vbaexpress.com/kb/getarticle.php?kb_id=693
After excel closes you can have the add-in uninstall itself.
oAddIn.Installed = False
You can give your add-in a setting for the user to not uninstall after every use by using a worksheet named something then have cell A1 equal to true or false.
I haven't tested this but hopefully it works for you.
This should work to resolve your issue though it does not instruct Excel regarding external links. I have tested it myself by creating the XLAM, saving it to my desktop, installing it in the Excel add-ins and then using it on a new workbook.
Steps:
Once you have saved the add-in, close it.
Go to Excel Options-->Add-Ins
In the Manage drop-down select Excel Add-ins and press 'Go'
In the 'Add-Ins'dialogue that appears click 'Browse' and navigate to
the add-in you just created. Select it and hit 'Ok'
If prompted to save the add-in in the add-ins folder, select 'No'.
Selecting 'Yes' may cause an error if the add-in file suffix does
not match the version of Excel being used.
Your add-in should appear in the 'Add-Ins available' scrollbox,
check its box and hit 'Ok'
Your add-in should now be active whenever you open Excel.
Test this by opening a new workbook and try using your UDF.
Best,
I usually solve this problem by:
Saving an XLA/XLAM file (outside Personal folder, of course)
Connect to it in Tools - Addins
Write pseudo macros in your current Excel file that links to those macros / functions in the XLA/XLAM file.
See the detailed instructions in my reply here.