Please someone help me to find sources to learn writing macros for MS Office Word. I am ended up with getting web pages for only "Recording macro" explained in different ways. While seeing those web pages i got to remember the sentence
"Sometimes people come up with awful analogies in an effort to describe a concept
which is too difficult for a regular person to understand.An infinite number of
monkeys hitting at an infinite number of typewriters for
an infinite amount of time will eventually produce all works of Shakespeare."
from infinite monkey theorm. Recording macro is very easy one. Most of the writers ended up with writing this article.
Please someone suggest me to learn writing Macros for MS Office Word. I am using Word 2007.
Since you are already familiar with the syntax, I suggest a site like this (its a cookbook approach): http://www.thezcorp.com/VBACodeSamples.aspx
Also, you can still press F2 to access the object browser and then filter the selection to just the Word library.
Related
Background and Problem
I lead a team of tech writers. Our team has a Word template (.dotm file) that has a bunch of VBA macros we've created over the years to help us automate tasks in Word. The macros are obviously stored inside of a .dotm template. Given that the code is stored in a binary file, the code is not easily traceable across commits.
Currently, we have to pull the changes on the branch and then open the macro inside Word's embedded code editor from the .dotm. But there's no way to see what exact code changes someone else made line by line or resolve conflicts using something like Beyond Compare.
What I Need
I'd like to find a way to automatically expose the VBA code from the .dotm as some kind of text file so that we can:
Do Word VBA coding tasks within VSC
Easily track and review each others code changes at the line level using our git repository
Resolve merge conflicts more easily
Has anyone found a way to do this?
What I've tried
I've tried searching online and on stackoverflow.
Hoping it might help, I installed ScriptLab, and I after following the MS tutorial, I now have Office Add-Ons working with VSC.
(https://code.visualstudio.com/docs/other/office),
(https://learn.microsoft.com/en-us/office/dev/add-ins/tutorials/word-tutorial) While the Office Add-Ons through VSC does provide an alternate (more modern) way of automating using Javascript, and the .js files are commit-able, it's not providing a way to expose the Word VBA, at least not that I could see.
Thank you in advance!
ScriptLab add-on is for playing with JavaScript code instantly, not designed as a macro infrastructure in Office.
Sounds like you need to switch your VBA macros to COM add-ins rails. There is no converters that can do this part of work for you automatically.
You may consider creating a VB.NET based add-in. In that case you will avoid language translating issues. You may find the Converting Code from VBA to Visual Basic .NET article helpful. It presents issues to consider when converting your Microsoft Office solutions from Visual Basic for Applications (VBA) to Visual Basic .NET. Provides a general overview of their differences, and then uses examples from Word and Excel to describe how you can use Visual Studio Tools for the Microsoft Office System to convert your code.
I have a general question and I'm not sure where to begin, literally. Can you please leave any direction at a fairly high level so I have the chance to try to figure it out for myself? Here's my initial plan, but here's the issue! I don't know where to start. Where would I begin with this? Would it be an Excel module? I need some direction guys!! Let me give you a quick run down of what we're trying to accomplish.
We start out with 2-3 customer specific spreadsheets with an account number + [static] file name.xlsx and about 7 generic template excel files where we use the data from the customer specific spreadsheets and save a copy of each of the template files in the customers store folder.
What I'm trying to figure out if VBA is the direction that I need to be going with this or if there is another method that would accomplish the same goal or be more efficient at getting it done. My thinking at this point is open one of the customers files, save the active workbook file path as a string (this would contain the file directory, division, customer number and customer name), split the string of the file path and save the information that I need as variables, open the appropriate template files based on division number, probably run a couple recorded macros then re-save the files using the account number in the appropriate directory. If there's anything else I left out for this to make more sense, please let me know and I'll re-edit the post. Thank you in advance for any guidance!!
I don't think you should use Access or VSTO - I'll explain why, then offer a practical way forward.
Access is way over the top for what you want to do: most people find it much easier to write code in Excel VBA (I speak as a trainer with 20 years of experience, who is a guru on both packages).
Visual Studio Tools for Office was Microsoft's attempt to get the business world to stop using VBA in Excel, and use the much more robust VSTO within Visual Studio. It's a great idea, but unfortunately not many people seem to be adopting it. In computing it's rarely a good idea not to go with the flow (and anyway, the learning curve for VBA is shorter than that for VSTO, IMHO - hope that's enough acronyms in one sentence!).
As to the practical solution: I've just finished writing a fairly large online tutorial in Excel VBA, which is at exactly the level you need, I think.
Good luck!
Since you are dealing with XLSX files then you are in Office 2007 or 2010, so you could use Visual Studio Tools for Office. This will allow you to use the .Net framework and C# or VB.Net in Visual Studio to get a better development experience than VBA. You could add your own ribbon and buttons to Excel to help accomplish your tasks.
One of my customers asked us to develop a "VBA macro". However, in the 2010s, it seems weird to me to still use such outdated language, and I'm thinking about trying to convince the customer to use VSTO dev instead. However, as I'm new to both worlds, I need help to fill a pro/cons page to be able to argue this.
Of course, the answer can't come without the actual requirement, let me try to resume:
Target : Word 2003/2007 (but I'm suspecting 2010 as a not yet known requirement) edit 2010 requirement confirmed
An external publishing system requires .doc file as input. The .doc file must have some specific styles applied : "Custom Header 1", "Custom header 2", etc.
The user can build documents, using Word, using two possible ways:
Start the new document using a .dot file deployed on the computer
Transform any existing document to match the target template
Users can "apply" the styles "simply" (simple UI): context menu, styles menu, custom action pane, etc.
By now, I see the following pro/cons:
VBA
Pros:
?
quick and dirty development (quick part of the sentence)
The customer has already some in production macro
Cons:
hard to find skilled developer
quick and dirty development (dirty part of the sentence)
VSTO
Pros:
benefits of the .Net language (compiled, typed, rigorous, class library, etc.)
security model more flexible and powerful (trusting code signed with a trusted authority)
bridge to WPF panes possible
You work in Visual Studio and have access to its full set of features: refactoring, source control, etc.
Cons:
requires installation of the .Net framework (probably not an issue today) and VSTO runtime
harder to deploy
slightly more work at the start (but less in long term)
I am not familiar enough to .NET but here is my humble opinion about VBA:
VBA
Pros :
easy to deploy and to make it work with the Office apps
quick and dirty development (quick part of the sentence) - agreed
Cons :
hard to find skilled developer
hard to select a skilled developer and explain your customer he needs to invest in this skill
quick and dirty development (dirty part of the sentence) - partial agreement. It will be dirty if:
you give the project to a VBA beginner and don't frame him/her
your project gets too big in terms of requirements
requires to have the .Net framework installed (probably not an issue today) I don't think so (maybe a CONS of VSTO?)
I would say that if you only want to have some code or add-in to merge some syles, you could easily do it with VBA and it won't be dirty (unless you really want it to).
I'm answering myself to the question, as the project is finished.
I finally decided to write the application using a VBA macro. Here is the post-mortem conclusion of this choice :
Pros:
The team that will maintains the application has no C# knowledge, only VBA (main reason of my choice).
Poor security model : it's a pro because there is no other setup that putting the files in the right place.
No runtime prerequisites
Cons:
The deployment was supposed to be simple.
I was counting of the possibility to play with Word options "User-template directory" and "Startup template directory". But it wasn't possible, because the app is not related to a specific entity in the customer organisation. I wasn't allowed to "take ownership" of this settings for this application.
I ended in writing a custom NSIS script to deploy the application on the correct folders. With VSTO, a simple setup project (clickonce?) would have done the job.
The language is so prehistoric ! Collections index starts to 1, array to 0, no OOP, poor out-of-the box language and library feature. That is not always a problem, but in my case, modeling the business rule was a bit painful (representing hierarchical data in a tree was not an easy job)
Very limited integration with source control (code, as it's embeded in the .dot files, was not historisable. Only the full .dot was)
Error management very limited with VBA
Poor IDE
Remark:
As an experienced C# developer, the pros/cons may be partial a bit.
I am a heavy Excel VBA developer.
VBA pro:
One of the major hurdles for me switching over to VSTO from VBA - and believe me, I love C# coding - is that there's no debug-on-the-fly which my userbase has got used to. I often jump straight into a VBA problem on the user's PC as it is happening, but with VSTO, that's not possible. (Unless someone can correct me.)
If your users have no such expectations this might be something you can easily live without.
VBA con:
VBA is one of the those languages that are easy to play with and thus easy to make a mess with. It doesn't enforce "clean coding" principles which means while decent programmers can make great applications with them, VBA can become associated with hackjobs and sprawling, organic code due to its low bar of entry. VBA developers are often considered a lower class of developer for this reason, when really there is a failure to distinguish between those that use it wisely and those that don't.
I doubt anyone chooses VBA as their career language of choice, it just sort of happens to them. Aside from being hard to find skilled developers, too much VBA work might turn away potential hires as they don't want to be associated with the "quagmire of another unmanaged VBA sprawl". Some people take use of VBA as a statement about how "serious" you are about technology.
(I tend to see Perl in the same light; great for short scripts but when someone used to using for scripting starts to use for a larger piece of work - you tend to get something that's a bit unwieldy.)
In this article I tried to summarize similar questions, in the context of Excel. Same arguments apply for all of the Office applications including word.
According to my observations :
VSTO :
CONS : that if we have developed Addins ribbons control for word 2007, we can only deploy with word 2007, but we can not deploy with word 2010 or word 2013.
This is major drawback for me to develop Addins for word and excel for all its versions like 2007, 2010 and 2013. plz correct me if am wrong or suggest me how could I develop Single Addins for all office version.
Has anyone come across a VBA (or other) program for implementing dynamic autocomplete in Word? Emacs has had this for decades, and it would be great to have it in Word. I see others in this forum are looking for code for Android, so this topic isn't completely obscure. It would be great to type ac* - and get Word to fill in "across" based on previous text.
Seemingly both Openoffice and MS Office has some sort of Auto-complete. I don't often use word processor though, but I hope it helps.
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.