So my question is a bit subjective to opinion, but I am a bit curious about using VBA vs the Microsoft Interop Excel Reference. I learned VBA before anything else, and I have since moved on to .net in order to design more powerful forms. How does the interop.excel reference work in regards to formatting a worksheet? Is it basically the same as using VBA in functionality? Such as formatting, say, column widths and rearranging data? As well, if you know VBA (which I do) is it better to design a .net app that runs the macros in the spreadsheet or just start re-learning how to do them at runtime in vb.net? Thanks for the advice.
Writing Excel formatting code in .net is (opinion) better than driving your macros. First you don't have to have the macros in Excel, second you have one place to modify your code. If you're a VBA person, you know that recording macros makes a mess of code, and then you have to strip it clean.
A couple things we've learned in my office with the Interop. Late Binding is safer than referenced objects as it can support different installed versions of office, as long as you don't include any functionality in your code that the least supported version of office can't handle. Also, always fully qualify your objects. By that I mean use
Dim XLApp as object = CreateObject("Excel.Application")
XLApp.Range("A1").font.bold=True
XLApp.Range("A1").font.size=12
Do not use
Dim XLApp as object = CreateObject("Excel.Application")
With XLApp.Range("A1")
.font.bold=True
.font.size=12
End With
There's a known issue with Office interop that the "with' clause can cause a reference to be created that no matter how well you clean up when your done, can be left hanging even after your application closes. You can test this for yourself by creating a test app, modify some settings in a worksheet, save it and close out. Under the write circumstances, open Task Manager, and Excel is still in your process list.
Hope this helps
Related
I recently wrote a form in VBA for Outlook and saved it to my personal form folder.
Now this form should get exported in a userfriendly fashion. What is the best practise here?
I know that you can go to File -> Export file... in VBA, but this seems to have caused some problems in the past and doesn't seem very intuitive to use both the frm and the frx files.
The form is supposed to be accessed by employees to book their holiday.
That is COM add-ins were invented for. They are designed to be installed on multiple machines and users. VBA macros are not designed for transferring the code - the infrastructure doesn't provide anything for moving solutions automatically like you could do in case of COM add-ins. You need have do that manually in VBA.
If you consider moving your solution to the add-in rails, see Walkthrough: Create your first VSTO Add-in for Outlook to get started quickly. You may choose VB.NET which has a similar syntax with VBA.
I am trying to develop add-ins because my organization wants to move away from macros, due to the logistical tasks of deploying to thousands of users.
Is there a guide to repurpose existing VBA code into add-ins?
I want to be able to view/modify the source code.
Most helpful article so far:
https://blogs.msdn.microsoft.com/csharpfaq/2010/09/27/converting-a-vba-macro-to-c-4-0/ where they suggest "recording a macro in Office and then use the results in their code in VS".
I'm not aware of any VBA to VB.NET conversion tools, but the similarities are enough that you can copy and paste most code and correct the differences on the individual lines that prevent compilation. However it would be necessary to have a decent working knowledge of VB.NET in order to do this effectively.
I would though recommend that this task be considered a complete re-write, especially since you need to port it to an add-in project. The way you call your VBA methods may differ greatly depending on whether they are event or UI/Ribbon driven.
Also note that there is no macro recorder for Outlook.
A bit of preface: this project, while technically homework, is completely under my 5-man team's control. We came up with the project, defined the scope, and exercise full creative control. So it's not traditional homework, it's equivalent to a senior project.
One of the outputs of the system I'm developing should be very similar to a well formatted Excel spreadsheet. We could create (or find) a graphics library and handle the printing in our own code... but ultimately we feel that an Excel spreadsheet file will be more portable. As the user can open it up in Excel, edit it, e-mail it, etc.
Accessing Excel programatically seems simple enough (i.e: http://support.microsoft.com/kb/302094)
But my question is: what happens when "Office 2013" comes out, and the user removes Office 2010 and installs 2013?
I won't be around to maintain this project... and I'd hate to force someone into opening up my code just to reference the Excel 13.0 COM.
I'll be using incredibly basic functions of the API.
So long as I can read-and-write to a range of cells, and adjust the interior color of cells, my code will work.
In general, how can I make my VB.Net code access whatever Microsoft Excel API is available on the target system? (Including future Excel APIs.)
I recommend first developing using the Excel PIA (Primary Interop Assemblies) so you get autocomplete and online help in Visual Studio.
Once your program is complete, I recommend switching to late-binding before publishing, so your EXE works with different versions of Excel.
Develop first using the current Excel PIA until it works as you
want (Google "Excel PIA" to download the assemblies)
When your program is complete, add Option Strict Off to the top of the modules that use Excel objects
Replace all Excel PIA classes with Object e.g.Dim xls As Excel.Application becomesDim xls As Object
Replace xls = New Excel.Applicationwith xls = CreateObject("Excel.Application")
Remove the Excel PIA reference and tidy up
I have a series of big excel files that work like a program, but I hate beeing tied up (stuck in VBA for excel 2003), so...
Whats the best way to implement a gui over a excel vba program (office 2003)? (are there any tools for that... I want to move away from the office suite, but still have it in the background)
Or what's the easiest alternative for migrating this code to a more open language.
Any ideias?
Have you looked at VSTO?
Resolver One is a Python spreadsheet system with strong support for importing from MS Excel. It's often used for the situation you describe.
I need interop in my programs to automate several functions in Word and Outlook. Does anyone know a good place to start. My goal is to kick off a mail merge, create several different files and save them accordingly, then e-mail the different files to different people based upon who needs what. Any help learning how to use the interop properly would be greatly appreciated.
I am currently using Visual Studio 2008 and Office 2007 and use vb.net to write my programs.
A good way to get started is to use the macro editor to record the steps you are trying to perform. You can take the generated macro code and modify it for your purposes to suit. Click on the names of functions and variables of which you do not know the purpose and hit "F1" to get context specific help.
Add COM references to Outlook 12.0 Object library and Word 12.0 Object library.
This web page really helped kick me off: http://support.microsoft.com/kb/316383
Then, by recording macros you'll expose a lot of the stuff you'll likely want to work with. Word of warning, however, is that not everything exposed in VBA (macros) is accessible within VB .NET. I don't know why this is, but I've actually had to construct and execute a macro from VB.NET, written in VBA, within Excel to accomplish something that seemed ridiculously easy if it weren't for the strange disconnect between the two.
Some good info on Mail Merge: http://support.microsoft.com/kb/258512
Here's an article with some basic steps to get you up and connected with Outlook's Interop: http://support.microsoft.com/kb/313787
Hope this helps. I'll keep an eye out for questions from you here--I'd say I know quite a bit when it comes to interop.
You might want to start here: http://msdn.microsoft.com/en-us/office/bb266408.aspx.
There are a number of tutorials.