T
tnemec78
During many days of testing of my Outlook add-in I came across an
interesting problem:
Every now and then my call to _MailItem::Move fails. I have no idea
why that is. I only observed that in such situations the Move
operation acts as a copy and it returns a failure status.
See below:
void MoveItem(CComPtr <Outlook::_MailItem> mi, CComPtr <MAPIFolder>
newfolder)
{
HRESULT hr;
CComPtr <IDispatch> ReturnedItem;
hr = mi->Move(newfolder, &ReturnedItem);
if( FAILED( hr ))
{
//here ReturnedItem == 0x00000000 although I can see that
the item *EXISTS* in the new folder
}
// ... more code ...
}
Although the new instance of the item exists, the old one was not
deleted. Despite this the ReturnedItem (ie. the new instance == 0)
Does anyone else have more experience with this issue? I would like to
know more about what can cause this, how to prevent this from
happening. If there is no way to do this then I suppose I only have to
mitigate the impact of this happening.
interesting problem:
Every now and then my call to _MailItem::Move fails. I have no idea
why that is. I only observed that in such situations the Move
operation acts as a copy and it returns a failure status.
See below:
void MoveItem(CComPtr <Outlook::_MailItem> mi, CComPtr <MAPIFolder>
newfolder)
{
HRESULT hr;
CComPtr <IDispatch> ReturnedItem;
hr = mi->Move(newfolder, &ReturnedItem);
if( FAILED( hr ))
{
//here ReturnedItem == 0x00000000 although I can see that
the item *EXISTS* in the new folder
}
// ... more code ...
}
Although the new instance of the item exists, the old one was not
deleted. Despite this the ReturnedItem (ie. the new instance == 0)
Does anyone else have more experience with this issue? I would like to
know more about what can cause this, how to prevent this from
happening. If there is no way to do this then I suppose I only have to
mitigate the impact of this happening.