VBA The NameSpace is the object that gives you access to all Outlook's folders.
In Outlook there is only one and it is called "MAPI" which is an acronym for Messaging Application Programming Interface.
We are going to be referring to a mail folder (a MAPIFolder object) which we have given the name Inbox but the macro won't know which actual folder that is until we tell it by giving the variable a value in the next step.
We will be using Atmt to refer to the attachment objects we are looking for.
The FileName variable is a text string that will be used to create a name and save path for each attachment as it is saved.
The integer variable i will be used as a counter to log the progress of the macro.
Most programming solutions interact with the data stored in Outlook. Outlook stores all of its information in Messaging Application Programming Interface (MAPI) folders. After you set an object variable to the Outlook Application object, you will commonly set a Namespace object to refer to MAPI, as shown in the following example.
Set objOL = New Outlook.Application
Set objNS = objOL.GetNameSpace("MAPI")
Set objFolder = objNS.GetDefaultFolder(olFolderContacts)
Once you have set an object variable to reference the folder that contains the items you wish to work with, you use appropriate code to accomplish your task, as shown in the following example.
Dim objOLApp As Outlook.Application
Dim NewTask As Outlook.TaskItem
' Set the Application object
Set objOLApp = New Outlook.Application
' You can only use CreateItem for default items
Set NewTask = objOLApp.CreateItem(olTaskItem)
' Display the new task form so the user can fill it out
Types of Events
Outlook events can be divided into two main categories: item-level events and application-level events.
Item-level events pertain to a particular item, and are typically handled by VBScript code contained within the form associated with the item. These events notify your program when an item has been opened, sent or posted, saved, or closed, and when the user has replied to or forwarded a message or initiated a custom action. Item-level events can also notify your program when the user has clicked a control on the form or when an item property has changed.
Application-level events are typically handled by Visual Basic or Visual Basic for Applications because they pertain to more than the items associated with a particular form. Application-level events can pertain to the application itself, to explorer collections and windows (including the Shortcuts pane), inspector collections and windows, folders and folders collections, items collections, and synchronization objects.
Responding to Events
To respond to item-level events, add event-handler procedures to the script of the form that displays the item. For example, to run code when an item is opened in the form, add a procedure like the following to the script in the form.
MsgBox "A new item has opened in this form."
Responding to application-level events is somewhat more involved because steps must be taken to associate the event handler with the part of Outlook in which the event is occurring. Learn about writing an application-level event handler .
Order of Events
Except for certain form events, your program cannot assume that events will occur in a particular order, even if they appear to be called in a consistent sequence. The order in which Outlook calls event handlers might change depending on other events that might occur, or the order might change in future versions of Outlook.
Security notes for COM add-in developers
COM Add-ins Using Default Security
In Microsoft Office Outlook 2003, all COM add-ins that run on a computer that is not configured to obtain security settings from a Microsoft Exchange Server are considered trusted by default. This implies that the add-ins that run on clients that are not Exchange clients and the add-ins that use default security in Exchange environments are trusted automatically. As in Microsoft Outlook 2002, Microsoft Office Outlook 2003 trusts only the main Application object that is passed to the OnConnection event of the add-in.
COM Add-ins Using Security Settings from an Exchange Server
There has been no change in the way Outlook 2003 trusts COM add-ins in an Exchange environment when the security settings are obtained from the Exchange server. An add-in will be considered trusted only if it is registered in the Security Settings folder. As in Outlook 2002, Outlook 2003 trusts only the main Application object that is passed to the OnConnection event of the add-in.
Improvements to Outlook Object Model Guard and the Impact
Outlook 2003 inherits the Outlook 2002 object model guard behavior and, in addition, blocks code that attempts to access the Body and HTMLBody properties of various Outlook items. This allows users to verify that the program or add-in accessing the Body and HTMLBody properties of these items is trustworthy, before they allow access to the contents of the items. Although this change forces the display of security warnings in existing COM add-ins that access the Body or HTMLBody properties of items, this will help prevent malicious code from running unknown to the user.
You can avoid the display of security warnings by deriving all objects, properties, and methods from the Application object passed to the OnConnection procedure of the add-in. Outlook 2003 trusts only the Application object passed to the OnConnection procedure of the add-in. If you create a new Application object, for example, by using the CreateObject method, that object and any of its subordinate objects, properties, and methods will not be trusted and the blocked properties and methods will raise security warnings.
New Object Model Blocks
The following are the additional properties that have been blocked in Outlook 2003:
The IMAddress property of a ContactItem object.
The HTMLBody property of a MailItem object.
The Body property of the following objects: ContactItem, MailItem, PostItem, AppointmentItem, TaskItem, TaskRequestItem, TaskRequestAcceptItem, TaskRequestDeclineItem, TaskRequestUpdateItem, DistListItem, JournalItem, MeetingItem, ReportItem, RemoteItem, NoteItem, or DocumentItem.
Also, if you use a third-party add-ins, custom solutions, or other programs that integrate with Outlook 2003, you may receive one or more of the following warnings:
"A program is trying to automatically send e-mail on your behalf. Do you want to allow this? If this is unexpected, it may be a virus and you should choose No. "
"A program is trying to access e-mail addresses you have stored in Outlook. Do you want to allow this? If this is unexpected, it may be a virus and you should choose No. "
These warning messages are commonly associated with software that is designed to synchronize Outlook data with handheld computers, but may occur with any type of add-in or custom solution.