Understanding Outlook's VBAProgramming and VBA scares a lot of people off. It's really not hard and many code samples are available on the Internet for you to use, so you don't even have to know how to program. But if you're unsure of whether you're ready for this, put it down, get yourself an introductory Visual Basic programming book, and come back to this hour when you feel you're ready.
There are many differences between how you create macros in Outlook compared to Word and Excel. First, you have to write the code yourself; you can't record it using a Macro recorder. Secondly, Word and Excel enable you to create a lot of modules that you can easily distribute to others. Outlook uses one module, C:\Documents and Settings\username\Application Data\Microsoft\Outlook\VBAProject.OTM , which contains all the macros the user created. All forms and modules are stored within this one file. If you give this file to someone and he uses it to replace his copy, he loses all previous macros he had.
There's so much to learn about writing your own Outlook code that it's better suited for a book specifically about Outlook programming. For that reason, I won't go over the object model or programming in depth; rather, I'll begin with entering your first macro. If you want to learn more, there are many resources and code samples available on the Internet. Because Outlook can do so much with code, Microsoft added security features to the object model to block unauthorized access to a number of Outlook features by other programs and VBA. Outlook 2003 eliminates the security prompts in properly constructed Outlook COM add-ins and published Outlook forms. Code in Outlook VBA also does not trigger security prompts because it's implemented as a COM add-in. However, using the code to access other COM add-ins or libraries will trigger the security warning. |