OL98: How to Properly Loop Through Items in a Collection

Retired KB Content Disclaimer

View products that this article applies to.

This article was previously published under Q195699

MORE INFORMATION

Microsoft provides programming examples for illustration only, without warranty either expressed or implied, including, but not limited to, the implied warranties of merchantability and/or fitness for a particular purpose. This article assumes that you are familiar with the programming language being demonstrated and the tools used to create and debug procedures. Microsoft support professionals can help explain the functionality of a particular procedure, but they will not modify these examples to provide added functionality or construct procedures to meet your specific needs.
If you have limited programming experience, you may want to contact a Microsoft Certified Partner or Microsoft Advisory Services. For more information, visit these Microsoft Web sites:

Microsoft Certified Partners - https://partner.microsoft.com/global/30000104 (https://partner.microsoft.com/global/30000104)

Microsoft Advisory Services - http://support.microsoft.com/gp/advisoryservice (http://support.microsoft.com/gp/advisoryservice)

For more information about the support options that are available and about how to contact Microsoft, visit the following Microsoft Web site: http://support.microsoft.com/default.aspx?scid=fh;EN-US;CNTACTMS (http://support.microsoft.com/default.aspx?scid=fh;en-us;cntactms)

Back to the top

Properly Referencing Members of a Collection

If you use Visual Basic or Visual Basic for Applications code that loops through items in a folder, you may see the modifications to those items are not saved. You may be unintentionally re-retrieving the item from the Items collection, and any changes that you have made to an item are unexpectedly lost.

Many Outlook solutions modify the contents of items in a folder. In most scenarios, you loop through the Items collection in the Outlook object model. If you do not properly reference the items in the collection, you may receive unexpected results.

Before modifying an item and saving it, you should set an object variable to the item, make changes to the item using the object variable, and then save the object.

Consider the following Visual Basic automation code sample, which is designed to reset the birthday field for each contact in the default Contacts folder:

NOTE: Be sure to reference the Outlook 98 Object Library before running these code examples and be aware running this code will modify any existing contacts you have in your Contacts folder.

   Sub ResetBirthdays1()
      Dim olns as Outlook.Namespace
      Dim oConItems As Outlook.Items
      Dim iNumItems As Integer
      Set ol = New Outlook.Application
      Set olns = ol.GetNamespace("MAPI")
      Set oConItems = olns.GetDefaultFolder(olFolderContacts).Items
      iNumItems = oConItems.Count
      For I = 1 to iNumItems
         oConItems.Item(I).Birthday = "1/1/4501"
         oConItems.Item(I).Close olSave
      Next
      Set oConItems = Nothing
      Set olns = Nothing
      Set ol = Nothing
   End Sub

In the previous sample, the loop is adequately structured and will process all of the items in the folder. However, within the loop, each time ConItems.Item(I) is executed, it retrieves the specific item from the collection of items. In this case, the Birthday is set for an item, but then then following line of code gets the item from the collection again. The end result is that an unmodified item is saved.

The following example is one way of modifying the previous code sample, so that it executes as expected:

   Sub ResetBirthdays2()
      Dim olns As Outlook.Namespace
      Dim oConItems As Outlook.Items
      Dim iNumItems As Integer
      Set ol = New Outlook.Application
      Set olns = ol.GetNamespace("MAPI")
      Set oConItems = olns.GetDefaultFolder(olFolderContacts).Items
      iNumItems = oConItems.Count
      For I = 1 to iNumItems
         Set oCurItem = oConItems.Item(I)
         oCurItem.Birthday = "1/1/4501"
         oCurItem.Close olSave
      Next
      Set oConItems = Nothing
      Set olns = Nothing
      Set ol = Nothing
   End Sub

In the previous sample, oCurItem is set to a specific item in the collection, modifications to the item are made using that object variable, and the object is saved. This avoids getting an item from the collection and losing any changes.

The following example provides the same functionality as the previous example, but uses the For Each...Next structure to loop through the items:

   Sub ResetBirthdays3()
      Dim olns as Outlook.Namespace
      Dim oConItems As Outlook.Items
      Set ol = New Outlook.Application
      Set olns = ol.GetNamespace("MAPI")
      Set oConItems = olns.GetDefaultFolder(olFolderContacts).Items
      For Each oCurItem in oConItems
         oCurItem.Birthday = "1/1/4501"
         oCurItem.Close olSave
      Next
      Set oConItems = Nothing
      Set olns = Nothing
      Set ol = Nothing
   End Sub

Back to the top

Deleting All Members of a Collection

If you want to programmatically delete all of the members of a collection, there are a few approaches that will work but there are also a number of approaches that will not work. Unexpected results occur because a collection is changing as you delete members from within it and the collection is not update dynamically. Typically you will find that every other item in the collection is deleted.

The following automation code example exhibits this behavior. Before running this code, create a subfolder of your Inbox called Test and copy (not move) some items into the folder so that they can be deleted.

   Sub DeleteItems()
      Set ol = New Outlook.Application
      Set olns = ol.GetNamespace("MAPI")
      Set TestFolder = olns.GetDefaultFolder(olFolderInbox).Folders("Test")
      Set TestItems = TestFolder.Items
      For Each Itm In TestItems
         Itm.Delete
      Next
   End Sub

To workaround this problem, delete the items from the collection in reverse order using the following approach:

   Sub DeleteItems()
      Set ol = New Outlook.Application
      Set olns = ol.GetNamespace("MAPI")
      Set TestFolder = olns.GetDefaultFolder(olFolderInbox).Folders("test")
      Set TestItems = TestFolder.Items
      NumItems = TestItems.Count
      For I = NumItems To 1 Step -1
         TestItems(I).Delete
      Next
   End Sub

Back to the top

Handling Unexpected Item Types

If you are looping through items in a folder, you should make sure your solution will work even if the folder contains items that you might not expect to be there. The Inbox typically poses the most concern since the user generally has less control over what items are placed in that folder.

Examples of items that you might unexpectedly find in a folder include:

A Meeting or Task Request item in the Inbox.
An item that is a file from an external source, such as a Microsoft Word document or a Microsoft Excel spreadsheet. These files may be directly posted into a folder from another application or they may have been dragged into a folder.
A Conflict message sent by Microsoft Exchange if more than one person has edited an item at the same time in a Public Folder.
An item that is based on a form designed using the Exchange Form Designer (EFD). These types of items may not function exactly like Outlook items in all circumstances. For example, you cannot programmatically add an attachment that is a link to an EFD-based item.
A "Distribution List" item in a Contacts folder. If you are using Outlook 98 in Internet Mail Only (IMO) mode you can create a distribution list using the Windows Address Book (WAB). These lists are stored -- but not exposed -- in the default Contact folder, but if you programmatically loop through the items in the folder, you will find items with a "IPM.DistList" message class.

Typically you will not run into problems when your code references one of these items. Problems usually occur when you try to reference a property of a particular item type and that property does not exist.

Following are approaches you can use to avoid these types of problems. Choose the approach that is best suited to your solution, the type of folder you are working with and the types of items that could potentially affect your solution.

Use the TypeName function to test the type of object being referenced:

      If TypeName(objMyItem) = "ContactItem" Then...

Check the MessageClass property of an item:

      If Left(objMyItem.MessageClass,11) = "IPM.Contact" Then...

Use error trapping to simply skip over lines of code that may potentially cause a problem:

      For Each oMyMailItem in oMyInboxItems
         On Error Resume Next
         oMyMailItem.VotingOptions = ""
         oMyMailItem.Save
      Next

Back to the top

REFERENCES

For more information about creating solutions with Microsoft Outlook 98, please see the following articles in the Microsoft Knowledge Base:

180826 (http://support.microsoft.com/kb/180826/EN-US/ ) OL98: Resources for Custom Forms and Programming

182349 (http://support.microsoft.com/kb/182349/EN-US/ ) OL98: Questions About Custom Forms and Outlook Solutions

Back to the top

SUMMARY

This article describes common scenarios and considerations to take into account when programming with collections. The following topics are covered:

Properly Referencing Members of a Collection
Deleting All Members of a Collection
Handling Unexpected Item Types

NOTE: The first two topics apply to all types of collections, including Items, Attachments, and Recipients. The last topic only applies to Items.

Back to the top

APPLIES TO

Microsoft Outlook 98 Standard Edition

Back to the top

kbprb kbprogramming KB195699

Back to the top

Retired KB Content Disclaimer

This article was written about products for which Microsoft no longer offers support. Therefore, this article is offered "as is" and will no longer be updated.

Back to the top