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
Related
Trying to save a MS Word macro as an add-in, fully independent, portable and installable as a word tool. What kind of literature should I consult to learn this technique?
So far I've tried looking on Google and StackOverflow. Many people ask similar questions, no one seems to provide a valid answer.
In the end, I would like to be able to export a macro in the form of a exe/batch/whatever to be summoned/installed from word and customize the tools ribbon permanently, to conceal the macro sourcecode and easily propagate to other machines.
It's not possible to use VBA macros as exe or batch files. It is possible, however, to load a macro-enabled template as an add-in. All the functionality will then be available (Ribbon, keyboard shortcuts, macros, building blocks).
Save the document as a dotm file (template, macro-enabled)
Copy the file in the STARTUP folder. Word will then load it automatically.
For a "real" add-in that uses the same COM object model as VBA it's necessary to build software based on the IDTExtensibility2 interface. There are number of tools that use this, making things easier. Microsoft's VSTO (Visual Studio Tools for Office) is one that costs nothing.
Another alternative is to use the newer Java Script APIs for Office. These are, in the case of Word, incomplete as far as functionality for the object model is concerned (can't do everything the COM object model is capable of).
I downloaded the Mini Calendar and Date Picker add-in from the Microsoft store and I would like to change a little bit of its functionality in VBA but cant seem to locate the add-in file anywhere . I activated the add-in and it works but it doesn't appear in the Active Application add-ins window under options so I don't know how to locate it. How can I go about this?
This is mentioned in the comments, but I'll officially answer as it's a common misconception that all Excel ADD-INS are written in VBA with an xlam file (particularly amongst financial Excel people who have just learned to write in VBA).
No. You cannot edit the code. It is not written in VBA and there is no xlam file, only a DLL file, which is much harder to interpret.
More "serious" add-ins, such as those found in Windows store, or are released by major software providers (SAP, Oracle, Microsoft) write their add-ins with C+, JavaScript or VB.Net. There's colossally more coding libraries in these languages than VBA, and the output of a DLL file makes it much harder for people to "steal" their code (as the OP intended to do, even if in a harmless nature).
So VBA enthusiasts won't be able to (easily) edit the code or learn from it.
I'm making a program that will eventually be used as a simple program to keep track of customers at a campground. I had originally made an excel spreadsheet for the owner where they could add how much each renter paid per month and I set it up in a way that it totaled each month and the whole year for him and displayed it like an accounting spreadsheet, with double underlines and the like. Now, he no longer has a copy of excel. I have set him up temporarily on google docs, but besides it not having all the functionality of excel, he doesn't trust it on the internet and has a hard time navigating to it.
What I'd like to do is create a program that would use forms to let him easily enter information, but display it either in the excel spreadsheet like he's used to seeing, or something that looks and prints pretty much the same.
I've seen people use SQL to work with access and excel. I'd like the connection string for that if anyone knows it. I have Visual Studio 2013 and I have Excel 2010 at home and work and 2013 at work.
My big question for you guys, that I can't find any information on is whether or not excel will work if I install the program on his computer that doesn't have excel installed? Does it work because it's part of the program? Can I only use the sheets and formulas that I set up when I created it? Can I generate new sheets using the program once it's installed on a pc that doesn't have excel installed on it? Thanks a lot for the help guys. I can't find information on this anywhere.
It depends what library you use. If you use Microsoft.Office.Interop.Excel than you will need to have the specific version of excel installed or at least a version that supports your interop assembly (my past experience was that it had to be exact).
The other option is to use another standalone third party library that reads the zipped XML files (.xlsx) and can manipulate it through that. Some libraries worth mention:
NPOI
EPPlus
ExcelLibrary
I have a substantial bank of VBA modules written in an Excel 2010 add-in. Some of these are specific to Excel, but many are more general. For example one takes a part number and re-formats it; another contains a Case Select function to find a file in a network drive.
I want to use the common functions in Word and Outlook. I could copy and paste from the Excel to Word add-ins, but this makes it difficult to keep my code up to date - when I make an edit in one application, I must remember to copy to all the others.
My question is, is there any means of writing common code in one place (e.g. in the Excel add-in, or some other common location) so that all MS Office applications can access it as it if it's just another module?
The way this used to be done was to take your code and compile it into a COM (or ActiveX) DLL using Visual Basic 6. Then you could add that DLL, using the VBA editor's "Tools...References" dialog, from any Office (or other) product that supported VBA, the same way you might use, say, the Microsoft Scripting Runtime, which is super-handy for things like Dictionary, FileSystemObject and TextStream.
Problem is, VB6 was released sometime in 1998 and has not been available from or supported by Microsoft for years now. There seem to be quite a few download sites offering the package - I can't offer any advice about the legality or security issues that might be experienced by using them...
Shamefully, Microsoft dropped the VBA ball years ago - it seems they mostly wish it would just Go Away.
You would need to create a COM add-in (.dll) for that, which would require Visual Studio or some other tool capable of creating COM exposed addins. There hasn't been any facility for this in Office since the old Office Developer edition.
VB6 is best way. VB6 is still supported for compiled programs. The IDE been tested and found to work up to Windows 10 (32 bit only) by MS but is unsupported.
If you want to convert to vbscript you can use wsc files instead of a dll.
From Script Components Overview
Windows® Script Components are an exciting new technology that allows you to create powerful, reusable COM components with easy-to-use scripting languages such as Microsoft® Visual Basic® Scripting Edition (VBScript) and Microsoft® JScript®.
Make one, make a type library, set a reference to typelibrary in Word and Excel.
Maybe can help somebody.
My solution has been set conditional compiler arguments in project properties:
In excel project: SOFT_EXCEL = 1 : SOFT_OUTLOOK = 0
In outlook project: SOFT_EXCEL = 0 : SOFT_OUTLOOK = 1
Then, in module:
Public Sub as_email()
#If SOFT_EXCEL Then
Debug.Print "this executes and compiles in excel"
#End If
#If SOFT_OUTLOOK Then
Debug.Print "this executes and compiles in outlook"
#End If
End Sub
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