vb6 uses vba for "macro" writing. I can find no documentation on how to do this.
This is a legacy VB6 program written sometime before 2004. I have requirements to update a small bit of it, but it requires editing of the user's macro. I cannot figure out how to "get at" the user's code.
I have the VB6 source code. My client purchased VBA from Microsoft. VBA for VB6 was also available from MSDN in September 2004 under the name "Microsoft Visual Basic for Applications 6.0 SDK Version 6.4 Release Handbook". There is one trivial example and poor documentation. The application allows the user to enter VBA code (most of the time a sort of question) like:
`Sex = Male
If Employee.Age = 16 Then
Print Employee.Name, Employee.Age
End if`
Some of the "questions" consist of a couple of hundred lines of code.
The VB6 program "somehow" executes the "question" and returns output to the user in a rich textbox.
When I look on the Web for VBA and VB6 (and i have done so with many variations) Google and Bing (among others) simply don't understand any questions about hooking VBA to VB6. There are applications (VISIO) which have included VBA. So somewhere, somebody, must know how to put VBA into an application (it is a COM afterall) or where decent documentation exists to accomplish this.
--Charlie
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
I have created a working Powerpoint add-in (.ppam) that offers several time saving features, and added a custom UI ribbon tab to improve accessibility.
As I look to distribute this add-in to users, I'm looking to improve code security by compiling it into a COM add-in (.dll) via VS Express.
I have looked all over the web for documentation on this, and have found some promising source, such as:
http://www.cpearson.com/excel/creatingcomaddin.aspx
Unfortunately, nearly everything I find appear to be quite outdated and based on Office XP or 2003, when I'm looking at Office 2010. I'm probably doing something wrong here, but I'm having trouble replicating their instructions on my end, running into errors like being unable to add a reference library or the code they suggest is not recognized. I actually am even unsure how to open for example the sample VB project that the Pearson site provides from the link above to imitate. I think all this may be because of the different versions of Office and Visual Studio, but could certainly be wrong.
Could anyone point me in the right direction? My understanding is that it's actually quite simple to convert the code from VBA to VB (just involves adding "Powerpoint.Application." in front of things like "activewindow"). So I just need to figure out how to convert a very simple VBA add-in into a COM add-in in VS Exp 2012 for Office 2010, and then can leverage the process to convert the full add-in.
Apologies if I'm using any of the terms incorrectly.
What is the difference between the two. I always thought VBA is somewhat 'crippled' version of VB, but when a friend asked me the other day I had no idea what the actual differences are.
Also, when you use, for example, Excel, is that VB or VBA ?
For nearly all programming purposes, VBA and VB 6.0 are the same thing.
VBA cannot compile your program into an executable binary. You'll always need the host (a Word file and MS Word, for example) to contain and execute your project. You'll also not be able to create COM DLLs with VBA.
Apart from that, there is a difference in the IDE - the VB 6.0 IDE is more powerful in comparison. On the other hand, you have tight integration of the host application in VBA. Application-global objects (like "ActiveDocument") and events are available without declaration, so application-specific programming is straight-forward.
Still, nothing keeps you from firing up Word, loading the VBA IDE and solving a problem that has no relation to Word whatsoever. I'm not sure if there is anything that VB 6.0 can do (technically), and VBA cannot. I'm looking for a comparison sheet on the MSDN though.
VBA stands for Visual Basic for Applications and so is the small "for applications" scripting brother of VB.
VBA is indeed available in Excel, but also in the other office applications.
With VB, one can create a stand-alone windows application, which is not possible with VBA.
It is possible for developers however to "embed" VBA in their own applications, as a scripting language to automate those applications.
Edit: From the VBA FAQ:
Q. What is Visual Basic for Applications?
A. Microsoft Visual Basic for Applications (VBA) is an embeddable programming environment designed to enable developers to build custom solutions using the full power of Microsoft Visual Basic. Developers using applications that host VBA can automate and extend the application functionality, shortening the development cycle of custom business solutions.
Note that VB.NET is even another language, which only shares syntax with VB.
Here's a more technical and thorough answer to an old question: Visual Basic for Applications (VBA) and Visual Basic (pre-.NET) are not just similar languages, they are the same language. Specifically:
They have the same specification: The implementation-independent description of what the language contains and what it means. You can read it here: [MS-VBAL]: VBA Language Specification
They have the same platform: They both compile to Microsoft P-Code, which is in turn executed by the exact same virtual machine, which is implemented in the dll msvbvm[x.0].dll.
In an old VB reference book I came across last year, the author (Paul Lomax) even asserted that 'VBA' has always been the name of the language itself, whether used in stand-alone applications or in embedded contexts (such as MS Office):
"Before we go any further, let's just clarify on fundamental point. Visual Basic for Applications (VBA) is the language used to program in Visual Basic (VB). VB itself is a development environment; the language element of that environment is VBA."
The minor differences
Hosted vs. stand-alone: In practical, terms, when most people say "VBA" they specifically mean "VBA when used in MS Office", and they say "VB6" to mean "VBA used in the last version of the standalone VBA compiler (i.e. Visual Studio 6)". The IDE and compiler bundled with MS Office is almost identical to Visual Studio 6, with the limitation that it does not allow compilation to stand-alone dll or exe files. This in turns means that classes defined in embedded VBA projects are not accessible from non-embedded COM consumers, because they cannot be registered.
Continued development: Microsoft stopped producing a stand-alone VBA compiler with Visual Studio 6, as they switched to the .NET runtime as the platform of choice. However, the MS Office team continues to maintain VBA, and even released a new version (VBA7) with a new VM (now just called VBA7.dll) starting with MS Office 2010. The only major difference is that VBA7 has both a 32- and 64-bit version and has a few enhancements to handle the differences between the two, specifically with regards to external API invocations.
Do you want compare VBA with VB-Classic (VB6..) or VB.NET?
VBA (Visual Basic for Applications) is a vb-classic-based script language embedded in Microsoft Office applications. I think it's language features are similar to those of VB5 (it just lacks some few builtin functions), but:
You have access to the office document you wrote the VBA-script for and so you can e.g.
Write macros (=automated routines for little recurring tasks in your office-work)
Define new functions for excel-cell-formula
Process office data
Example: Set the value of an excel-cell
ActiveSheet.Cells("A1").Value = "Foo"
VBC and -.NET are no script languages. You use them to write standalone-applications with separate IDE's which you can't do with VBA (VBA-scripts just "exist" in Office)
VBA has nothing to do with VB.NET (they just have a similar syntax).
Actually VBA can be used to compile DLLs.
The Office 2000 and Office XP Developer editions included a VBA editor that could be used for making DLLs for use as COM Addins.
This functionality was removed in later versions (2003 and 2007) with the advent of the VSTO (VS Tools for Office) software, although obviously you could still create COM addins in a similar fashion without the use of VSTO (or VS.Net) by using VB6 IDE.
It's VBA. VBA means Visual Basic for Applications, and it is used for macros on Office documents. It doesn't have access to VB.NET features, so it's more like a modified version of VB6, with add-ons to be able to work on the document (like Worksheet in VBA for Excel).
VB is not a language. VB is a program that hosts VBA, just as Office hosts VBA. VB is a set of App objects, just like Word and Excel have, and a forms package, just like in Office.
So you can only write VBA code in VB.
PS this info is on the INFO tab on the VB question page for VB.
From VBA Info
VBA 6, was shipped in 1998 and includes a myriad of licensed hosts, among them: Office 2000 - 2010, AutoCAD, PI Processbook, and the stand-alone Visual Basic 6.0
VBA stands for Visual Basic For Applications and its a Visual Basic implementation intended to be used in the Office Suite.
The difference between them is that VBA is embedded inside Office documents (its an Office feature). VB is the ide/language for developing applications.
VB (Visual Basic only up to 6.0) is a superset of VBA (Visual Basic for Applications). I know that others have sort of eluded to this but my understanding is that the semantics (i.e. the vocabulary) of VBA is included in VB6 (except for objects specific to Office products), therefore, VBA is a subset of VB6. The syntax (i.e. the order in which the words are written) is exactly the same in VBA as it would be in VB6, but the difference is the objects available to VBA or VB6 are different because they have different purposes. Specifically VBA's purpose is to programatically automate tasks that can be done in MS Office, whereas VB6's purpose is to create standard EXE, ActiveX Controls, ActiveX DLLs and ActiveX EXEs which can either work stand alone or in other programs such as MS Office or Windows.
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.