The property 0x3FFA001F that they ignore is PidTagLastModifierName see here. Don’t chain COM calls such as ġ7:43:23 Conflict generated, remote item is winner Studying the modification resolution log.If a call to an Outlook (actually, any Office application!) property/method returns an object, that object is a COM object and you should release it.That means that the first step to solving any issue with your code using the Outlook Object Model (OOM) is to make sure you release all COM objects your code creates. Outlook is known for a great number of misbehavior scenarios starting with your code leaving a COM object unreleased. Getting any issue in that event isn’t expected. At, Microsoft demonstrates doing this in the Contacts folder. BackgroundĪdding a UserProperty to an Outlook item in the ItemAdd event is a usual practice. This solution may be a limited one see below. Instead, add the UserProperty while sending the email – in the ItemSend event. Do not use the ItemAdd event to modify the item in this case. During that time, mail items are generated in Sync Issues and Sync Issues | Conflicts folders. The issue shows itself as follows: after the add-in handles the event, the category is visible in the Explorer view for several seconds then the category mark as well as the UserProperty disappear. To detect the issue easily, I suggest that your code also change the MailItem.Category property before saving the item. In the ItemSend event of the Sent Items folder, your code adds a UserProperty to the Outlook item that the event handler supplies (and saves the item). The Outlook version used (Outlook 365 in my case) seems to be irrelevant as Google reports a similar conflict to occur in Outlook 2007. Reportedly, turning the Cached Mode off solves the issue. I see this issue in the Sent Items folder on an Exchange account having Cached Exchange Mode (see e.g.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |