IProfSect : IMAPIProp

This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.

Works with the properties of profile section objects.

Vtable Order

This interface does not have any unique methods.

Notes to Callers

The IProfSect interface does not have any unique methods of its own, but you can call the profile section's IMAPIProp methods. There are some differences between the IProfSect implementation and other implementations of IMAPIProp:

• IProfSect does not support a transaction model.

• IProfSect does not support named properties.

• IProfSect reserves the identifier range 0x67F0 to 0x67ff for secure properties.

Not supporting a transaction model means that all changes that were made to a profile section following calls to the IMAPIProp::CopyProps and IMAPIProp::CopyTo methods occur immediately. Calls to the IMAPIProp::SaveChanges method succeed but do not actually save any changes.

To be protected from changes that occur prematurely, service providers need to make copies of their profile sections that are displayed to users through property sheets. The property sheets should work with the copy, instead of the real profile section. When the user clicks the OK button to verify that the changes are accurate, the changes can be saved to the real profile section.

To implement a property sheet by using a copied profile section, use the following procedure:

1. Open the profile section by calling the IMAPISupport::OpenProfileSection or IProviderAdmin::OpenProfileSection method.

2. Call the CreateIProp function to retrieve a property data object — an object that supports the IPropData interface.

3. Call the profile section's IMAPIProp::CopyTo method to copy the properties that will appear on the property sheet from the profile section to the property data object.

4. Call the IMAPISupport::DoConfigPropSheet method to request that the service provider display a property sheet, and pass a pointer to the property data object in the lpConfigData parameter.

5. When the user saves changes to configuration properties in the property sheet, call the IMAPIProp::CopyTo method to copy the properties from the property data object back to the profile section.

Profile sections, unlike other objects, do not support named properties. The IMAPIProp::GetIDsFromNames and IMAPIProp::GetNamesFromIDs methods return MAPI_E_NO_SUPPORT if they are called on a profile section object. If you use the IMAPIProp::SetProps method to set property identifiers in the range above 0x8000, the PT_ERROR property type will be returned.

Profile sections reserve the identifier range 0x67F0 to 0x67FF for secure properties. Service providers can use this range to store passwords and other provider-specific credentials. Properties in this range are not returned in the complete list of properties when NULL is passed in the lpPropTag parameter of the IMAPIProp::GetProps method, nor are they returned in the lppPropTagArray parameter of the IMAPIProp::GetPropList method. Secure properties must be requested specifically by their identifiers.

MAPI furnishes a profile section with the hard-coded constant MUID_PROFILE_INSTANCE as its identifier and PR_SEARCH_KEY (PidTagSearchKey) as its single property. MAPI ensures that the PR_SEARCH_KEY property value will be unique among all created profiles. Use PR_SEARCH_KEY instead of PR_PROFILE_NAME when uniqueness is important, because it is possible for a deleted profile to be followed by another profile with the same name.

For more information about how to use profile sections, see Administering Profiles and Message Services.

See Also

Concepts

MAPI Interfaces