The operation failed.

  • Thread starter Thread starter j
  • Start date Start date
J

j

Hi all.

I develop vsto addIn 2005, OL 2003, C# 2.0

One of my customer sometime got comException -->
System.Runtime.InteropServices.COMException (0xB174010F): The
operation failed.
at Microsoft.Office.Interop.Outlook.MAPIFolder.get_Name()

In the code we try to get Folder's name.

Why this happen??
How can i recover from this error?? (otlook restart helps, but this is
not solution.)

Thanks in advance.
 
The obvious question is if that MAPIFolder object is valid when you ask for
the folder name? Do you check that? If it is a valid folder I can't think of
a reason why the name isn't available.

In general with COM addins you should be handling all possible errors. With
managed code you have to do even more exception handling than you would with
unmanaged code, things are less forgiving with managed code. You need to put
try...catch blocks around any code that could fire an exception, and you
need to test for things such as properties like EntryID. In unmanaged code
an item that was never saved will have a null string EntryID, in managed
code the property may not be there. So you'd need to test for
String.IsNullOrEmpty().

You should also not use compound dot operators, which create invisible
variables you can't release, and which make it impossible to see exactly
where any code is failing.
 
The obvious question is if that MAPIFolder object is valid when you ask for
the folder name? Do you check that? If it is a valid folder I can't thinkof
a reason why the name isn't available.

In general with COM addins you should be handling all possible errors. With
managed code you have to do even more exception handling than you would with
unmanaged code, things are less forgiving with managed code. You need to put
try...catch blocks around any code that could fire an exception, and you
need to test for things such as properties like EntryID. In unmanaged code
an item that was never saved will have a null string EntryID, in managed
code the property may not be there. So you'd need to test for
String.IsNullOrEmpty().

You should also not use compound dot operators, which create invisible
variables you can't release, and which make it impossible to see exactly
where any code is failing.













- Show quoted text -
Click to expand...


Thanks for replay,

can please explain what you meant by saying :
The obvious question is if that MAPIFolder object is valid when you ask for
the folder name? Do you check that? If it is a valid folder I can't think of
a reason why the name isn't available.
Click to expand...

How should i check if this object valid??? some sample will help.

Also, some time i got comException when trying to access the toolbar:
"Microsoft.Office.Interop.Outlook.ExplorerClass.get_CommandBars"

what can i do on the subject.

Thanks.
 
Before using something like this:

Debug.WriteLine(folder.Name);

You should use code something like this:

if (folder != null)
{
Debug.WriteLine(folder.Name);
}

The same thing applies to any other object such as a CommandBar.




<snip>
Thanks for replay,

can please explain what you meant by saying :
The obvious question is if that MAPIFolder object is valid when you ask for
the folder name? Do you check that? If it is a valid folder I can't think
of
a reason why the name isn't available.
Click to expand...

How should i check if this object valid??? some sample will help.

Also, some time i got comException when trying to access the toolbar:
"Microsoft.Office.Interop.Outlook.ExplorerClass.get_CommandBars"

what can i do on the subject.

Thanks.
 
Before using something like this:

Debug.WriteLine(folder.Name);

You should use code something like this:

    if (folder != null)
    {
        Debug.WriteLine(folder.Name);
    }

The same thing applies to any other object such as a CommandBar.




<snip>
Thanks for replay,

can please explain what you meant by saying :


How should i check if  this object valid??? some sample will help.

Also, some time i got comException when trying to access the toolbar:
"Microsoft.Office.Interop.Outlook.ExplorerClass.get_CommandBars"

what can i do on the subject.

Thanks.
Click to expand...

Thank you,

I got it, now my question is what should i do if i get null in
COMMANDBARS??
by the way i'm moreo then sure, that these objects not NULL, and still
they ends up with ComExcpetion.

What do you say??
 
If a MAPIFolder is not null then you can get its properties. Set a
breakpoint at that line of code and use the Locals window to see what
properties are exposed on that COM object. Same thing for CommandBars.

Any Explorer will have a valid CommandBars collection. If you get a valid
Explorer I can't see why you wouldn't be able to get the CommandBars
collection for it. Again, use the Locals window to see what's up.




<snip>
Thank you,

I got it, now my question is what should i do if i get null in
COMMANDBARS??
by the way i'm moreo then sure, that these objects not NULL, and still
they ends up with ComExcpetion.

What do you say??
 
this is my code:

OL.MAPIFolder mapiFolder = GetDedicatedFolderForUserID(userID);

if (mapiFolder != null)
{
folderName = mapiFolder.Name;
}

and i get exception:
System.Runtime.InteropServices.COMException (0x8624010F): The
operation failed.
at Microsoft.Office.Interop.Outlook.MAPIFolder.get_Name()
at
ActionBase.Office.OutlookAddIn.Managers.OutlookFolderManager.GetDedicatedFolderNameForUserID
(Int64 userID)

So, the object is valid. It's not null, so i suppose that it valid.
And why this strange exception occured?, it's happen from time to
time, very seldom, but may occur.

Any ideas??
 
You're going to have to do detective work on that. Does this happen on a
repeatable basis with certain folders? How are those folders opened, are
they part of a PST file or Exchange mailbox or Exchange public folders or
delegate mailboxes? Are they from custom stores?

If this is totally random and not repeatable at all, even on the same
folder, then that's one of the hardest things to figure out. If you can
discern some pattern that will lead to a solution.
 
You're going to have to do detective work on that. Does this happen on a
repeatable basis with certain folders? How are those folders opened, are
they part of a PST file or Exchange mailbox or Exchange public folders or
delegate mailboxes? Are they from custom stores?

If this is totally random and not repeatable at all, even on the same
folder, then that's one of the hardest things to figure out. If you can
discern some pattern that will lead to a solution.















- Show quoted text -
Click to expand...


Hey,

It's not happen on a repeatable basis, and these folders are part of
Exchange mailbox.
the same thing with CommandNBars.

I need some solution or workaround to recover from that strange issue.
What do u say??
 
What I say is you are going to have to do the detective work on this.

Any random problem is very hard to debug and we can't do that for you, we
can't see what's going on or know all of your code.




<snip>
Hey,

It's not happen on a repeatable basis, and these folders are part of
Exchange mailbox.
the same thing with CommandNBars.

I need some solution or workaround to recover from that strange issue.
What do u say??
 
What I say is you are going to have to do the detective work on this.

Any random problem is very hard to debug and we can't do that for you, we
can't see what's going on or know all of your code.




<snip>
Hey,

It's not happen on a repeatable basis, and these folders are part of
Exchange mailbox.
the same thing with CommandNBars.

I need some solution or workaround to recover from that strange issue.
What do u say??
Click to expand...

Ken I agree with you,

However there is known comExeption "The operation failed". -->
System.Runtime.InteropServices.COMException (0xB174010F): The
operation failed.

it's occured while i trying to get folder's name:
if (mapiFolder != null)
{
folderName = mapiFolder.Name;
}
also, i don't get NullReferenceException, so probably should b e some
reason for that.
It's very weired.
 
It is odd, but the only other thing I can suggest is to open a paid support
incident with MS and let them try to debug it.




<snip>
Ken I agree with you,

However there is known comExeption "The operation failed". -->
System.Runtime.InteropServices.COMException (0xB174010F): The
operation failed.

it's occured while i trying to get folder's name:
if (mapiFolder != null)
{
folderName = mapiFolder.Name;
}
also, i don't get NullReferenceException, so probably should b e some
reason for that.
It's very weired.
 
It is odd, but the only other thing I can suggest is to open a paid support
incident with MS and let them try to debug it.




<snip>
Ken I agree with you,

However there is known comExeption "The operation failed". -->
 System.Runtime.InteropServices.COMException (0xB174010F): The
operation failed.

it's occured while i trying to get folder's name:
   if (mapiFolder != null)
            {
                folderName = mapiFolder.Name;
            }
also, i don't get NullReferenceException, so probably should b e some
reason for that.
It's very weired.
Click to expand...

Ken, ...

I figured out some fact.
The call to routine (that return folderName) is called by backgorund
thread, not Outlook main thread.
Also, the the reference to this folder is not stored as object but ,
storeid and entryid stored. I get the
mapiFolder object by using ...Session.GetFolderFromID function.

Does make sense ??

Thanks in advance.
 
Never, ever call into the Outlook object model from a background thread. The
OOM should only be called from the main thread of your addin. Outlook will
crash, hang or otherwise not be reliable if the OOM is called from a
background thread. That's been documented ever since Outlook 97.

If you need a call from a background thread then do so after synching your
call back to the main thread context, or pass the string properties for
EntryID and StoreID back to the main thread, let that get the object and
extract any properties needed and then pass them back as strings or ints or
whatever.

That sort of information (the background thread) is something we couldn't
have known from looking at the code you had showed. It's why without
complete information we often can't help, Internet mind reading still isn't
very reliable <g>




<snip>

Ken, ...

I figured out some fact.
The call to routine (that return folderName) is called by backgorund
thread, not Outlook main thread.
Also, the the reference to this folder is not stored as object but ,
storeid and entryid stored. I get the
mapiFolder object by using ...Session.GetFolderFromID function.

Does make sense ??

Thanks in advance.
 
Never, ever call into the Outlook object model from a background thread. The
OOM should only be called from the main thread of your addin. Outlook will
crash, hang or otherwise not be reliable if the OOM is called from a
background thread. That's been documented ever since Outlook 97.

If you need a call from a background thread then do so after synching your
call back to the main thread context, or pass the string properties for
EntryID and StoreID back to the main thread, let that get the object and
extract any properties needed and then pass them back as strings or ints or
whatever.

That sort of information (the background thread) is something we couldn't
have known from looking at the code you had showed. It's why without
complete information we often can't help, Internet mind reading still isn't
very reliable <g>




<snip>

Ken, ...

I figured out some fact.
The call to routine (that return folderName) is called by backgorund
thread, not Outlook main thread.
Also, the the reference to this folder is not stored as object but ,
storeid and entryid stored. I get the
mapiFolder  object by using ...Session.GetFolderFromID function.

Does make sense ??

Thanks in advance.
Mmmmmm...

If you need a call from a background thread then do so after synching your
Click to expand...
call back to the main thread context

How i do such thing in OOM ?? How can i synch call back to the main
thread context? Can u explain?

ALso in such way (i'll perform all my executions in main thread) then
the Outlook will be unrespansible.
THe addIn has a lot of thing to do, that's why we use one background
thread in the addIn.
 
All object model calls and use of the object model *must* be on the main
thread. If that makes Outlook unresponsive then you need to re-architect
your solution. Using a background thread for OOM calls will definitely cause
problems for you and everyone else and is not supported.

A bad architecture is no excuse for doing things incorrectly.

You would need to get the current thread context in the main thread. I
usually do it in NewInspector and Explorer.SelectionChange. I check if my
class level context is not null and if it is null I get the current context
after calling to Windows.Forms.Application.DoEvents() to prime the message
pump. Without that you usually can't get the context.

Then from the background thread you get that context and use a SendOrPost
callback. Once that's set the call you make is routed to the callback you
set up and that runs on the main thread. You can google for various
threading members and on SendOrPost to see more about that.




If you need a call from a background thread then do so after synching your
Click to expand...
call back to the main thread context

How i do such thing in OOM ?? How can i synch call back to the main
thread context? Can u explain?

ALso in such way (i'll perform all my executions in main thread) then
the Outlook will be unrespansible.
THe addIn has a lot of thing to do, that's why we use one background
thread in the addIn.
 
All object model calls and use of the object model *must* be on the main
thread. If that makes Outlook unresponsive then you need to re-architect
your solution. Using a background thread for OOM calls will definitely cause
problems for you and everyone else and is not supported.

A bad architecture is no excuse for doing things incorrectly.

You would need to get the current thread context in the main thread. I
usually do it in NewInspector and Explorer.SelectionChange. I check if my
class level context is not null and if it is null I get the current context
after calling to Windows.Forms.Application.DoEvents() to prime the message
pump. Without that you usually can't get the context.

Then from the background thread you get that context and use a SendOrPost
callback. Once that's set the call you make is routed to the callback you
set up and that runs on the main thread. You can google for various
threading members and on SendOrPost to see more about that.






call back to the main thread context

How i do such thing in OOM ?? How can i synch call back to the main
thread context? Can u explain?

ALso in such way (i'll perform all my executions in main thread) then
the Outlook will be unrespansible.
THe addIn has a lot of thing to do, that's why we use one background
thread in the addIn.
Click to expand...

Thanks Ken,

And what about marking bakground thread as STA
please see the snippet(C#) below:

Thread thNew = new Thread(new ThreadStart (MyMethod));
thNew.ApatrmentState = ApartmentState.STA;


What do you say??
 
If you're asking if making a background thread STA would allow it to call
into the Outlook object model, the answer is no.

Background thread calls to the OOM are not supported in any way, shape or
form.

You need to either do the OOM calls on the main thread and pass things like
strings to the background thread or synch the thread context to the main
thread when making calls like that.




<snip>

Thanks Ken,

And what about marking bakground thread as STA
please see the snippet(C#) below:

Thread thNew = new Thread(new ThreadStart (MyMethod));
thNew.ApatrmentState = ApartmentState.STA;


What do you say??
 
Back
Top