Is it possible to write VB.NET code to be used in an Excel spreadsheet without using Visual Studio? In other words, is there a built-in VB.NET editor for Excel that can be easily accessed like the built-in VBA editor? Or can I coerce the built-in VBA editor to allow me to write VB.NET code?
If the answer is no, do you know why Microsoft has not implemented this in Excel? It seems the ease of accessing the VBA editor is one of the reasons people still write new VBA code today. If Microsoft wants to be rid of VBA then why not make VB.NET more accessible in Excel? I'm not interested in speculation but instead any official word from Microsoft.
Some direct answers to the direct questions:
is there a built-in VB.NET editor for Excel that can be easily accessed like the built-in VBA editor?
Answer: No
Or can I coerce the built-in VBA editor to allow me to write VB.NET code?
Answer: No
If the answer is no, do you know why Microsoft has not implemented this in Excel?
Answer: since I'm not a Microsoft insider, No (but I could speculate...)
There are, of course, a variety of non-built in ways to interact with Excel. But I'm sure you already know that.
That's kind of a silly question. The internal language for MS Excel currently happens to be VBA. And frankly. VBA is pretty darn close to both VB6 as well as VB.Net, IMHO. Certainly the two are more similar than, say C++, Java, Perl or any of a million other languages.
So why isn't doesn't Excel use VB.Net (or, for that matter, C#)? Because Excel doesn't come with its own .Net runtime, and doesn't require you to have a .Net runtime to use it.
So why can't use use VB.Net (or C#) with Excep? If course you can use them with Excel. You can write a VB.Net program that reads and writes Excel spreadsheets, that invokes Excel functionality, that uses Excel as a datasource, etc etc etc.
So what more could you ask for ;)?
Related
This might be as rare as a ginger unicorn, however, is there a source-to-source (transcompiler) that compiles down to vba?
I've got some c# financial functions that would be great to reuse in vba.
So after much searching it appears there isn't a transcompiler available as of 06/Aug/2014.
It would appear that people either:
(a) code directly in vba and accept the limitations of the language and tooling
or
(b) create a c# dll and reference from the vba host
e.g. A Simple C# DLL - how do I call it from Excel, Access, VBA, VB6?
I recently learned that I could create Office Word macros with Visual Basic, but is it possible to use a different language? Visual Basic is ok for beginners, but I want to know if it's possible to use different languages, and how to set them up.
PS: Is lua possible at all? I love lua. I immagine lua would be a good macro language.
This related question is a good example of using lua with Excel. It in fact contains a lot of documentation about getting lua/Excel talking.
You can't directly work with other languages in Excel the way you can VBA. However, a lot of languages do have the ability to create COM objects (such as in the example above) which let you interact with Excel quite similarly to how you otherwise would do in VBA. Here's a Python package which does similarly.
But if you want to basically write lua code in the VBA editor and "change language" then no, you can't.
I just came to know that macros in Word/Excel/PowerPoint can be programmed. That is awesome because I've a Word document with 70 tables for styling.
I'm a programmer but I don't know VB, VBA or VB .NET. I'm confused with these three. I'm familiar with .NET programming using C#. Now I want to write new macros. Where should I get started? What are VB, VBA, VB.NET and which one should I learn? Please suggest some material.
If I learn for Word 2007 will that help with other Office applications life Excel & PowerPoint?
Here's a brief explanation of the different Visual Basics:
Visual Basic 6 (VB6, or classic VB)
Released around 1998, this was the last iteration of Microsoft's original "Visual Basic." It has the beginnings of object-oriented development, but it requires the Visual Basic Runtime for applications to run. A lot of companies have used VB6 for internal business applications. It was superceded by VB.NET and the .NET Framework.
Visual Basic for Applications (VBA)
VBA shares the same code base as VB6 and in 1996 was available to be licensed to developers to include in their own applications. This is how VBA appears in Microsoft Office, as an embedded language that can be used to control Office's various applications. It's important to remember that VBA, which is still used to code office applications, is over a decade old and may feel as such when one is used to working with .NET.
Visual Basic .NET (VB.NET)
VB.NET was a radical departure from VB6. Though subsequent iterations of VB.NET have been referred to in sequence (e.g. VB7, VB8, etc.) by many developers, VB.NET shares very little with VB6 and VBA other than the BASIC syntax. Many consider it more of a new evolution in BASIC rather than an evolution in Visual Basic. Because it's entirely different from VBA and VB6, you cannot not use VB.NET code directly in VBA.
Because VB.NET code compiles down to the same managed intermediate language code as C# and shares the same .NET APIs, you may feel more commonality between C# and VB.NET than VB6 and VB.NET from a programming perspective.
If you anticipate doing a lot of development in VBA, I would highly recommend the VBA Developer's Handbook, Second Edition, by Getz and Gilbert.
Learning the VBA syntax for Word will certainly help you when you go to use Excel, Access, etc. However, each application has its own API that provides a set of objects and methods unique to its domain. For example, I'm very familiar with programming in VBA in Excel and Access, but I have never done macro programming in Word. Although the code syntax would be the same, I'd have to learn Word's API to be able to program against it.
The nice thing about some of the Office applications (Excel, for example) is that you can record a macro, see what code it generates, and then tweak that code to do what you want. That's largely how I got started in programming.
There are some good answers here - I'd like to offer one more set of suggestions:
First, if supported in your environment, you can use Visual Studio 2005/8/10 and your C# skills to program against Office with "Visual Studio Tools for Office". See this thread for more details.
If you want to delve into VBA instead (which I personally love because development is so fast compared to VS), start with this article Ten Code Conversions for VBA, Visual Basic .NET, and C# which will show you samples from all three languages. Next, watch this webcast: Using Visual Basic for Applications (VBA) Every Day Is Easier Than You Think.
Thirdly- MSDN, read through this: Getting Started with VBA in Word 2010. 99% of it applies to Word 2007. There are many other articles linked from this one or you can always go to the main page of Office VBA Developer Center as a single jump page.
Then it's probably time to get started to directly program. See how things work, learn Word's Object Model, etc. You can always browse SO under the word-vba tag to see what other people are trying to do and the answers.
You always have MSDN.
If you go to Microsoft Word > Developer > Visual Basic and open up ThisDocument in the left menu, you will have the editor. If you press F2 you will get the libraries that can be used in Microsoft Word (the Object Browser). The easiest program would be the following:
Sub Hello()
MsgBox "Hello World"
End Sub
When you have the sub marked, press F5 (to run).
In the Object Browser you will have three different objects, properties, functions and events. When you see something that strikes your interest, go to the reference for word vba and locate it.
[If the link changes, you can find it in the tree under MSDN Library > Office Development > 2007 Microsoft Office System > Word 2007 > Word 2007 Developer Reference > Word Object Model Reference]
I think the easiest thing to do is to define a problem you need fixed and try to program it, similar to learning any other language. Don't make the problem to easy, but not to hard that you give 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.