The operation failed.

[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.

 

[Ken Slovak - [MVP - Outlook]]

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.

"j" <Evgeny.Br@gmail.com> wrote in message

news:cd8e6b28-3e41-416f-9f8f-716e808a37fb@r2g2000yqm.googlegroups.com...
> 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.

 

[j]

On Jul 28, 4:13 pm, "
<kenslo...@mvps.org> wrote:
> 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.

> >

> http://www.slovaktech.com

> "j" <Evgeny...@gmail.com> wrote in message

> news:cd8e6b28-3e41-416f-9f8f-716e808a37fb@r2g2000yqm.googlegroups.com...

>
> > 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.-



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.

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.

 

[Ken Slovak - [MVP - Outlook]]

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.

"j" <Evgeny.Br@gmail.com> wrote in message

news:387823b4-acb3-4232-9ac0-9fa9db60bff3@g31g2000yqc.googlegroups.com...

<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.

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.

 

[j]

On Jul 28, 5:32 pm, "
<kenslo...@mvps.org> wrote:
> 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.

> >

> http://www.slovaktech.com

> "j" <Evgeny...@gmail.com> wrote in message

> news:387823b4-acb3-4232-9ac0-9fa9db60bff3@g31g2000yqc.googlegroups.com...
> <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.

> 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.

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??

 

[Ken Slovak - [MVP - Outlook]]

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.

"j" <Evgeny.Br@gmail.com> wrote in message

news:f4adea4d-1f49-418b-82fc-c4476abdb6de@s15g2000yqs.googlegroups.com...

<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??

 

[j]

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??

 

[Ken Slovak - [MVP - Outlook]]

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.

"j" <Evgeny.Br@gmail.com> wrote in message

news:e3670e3d-d5e6-4a18-9666-00701f0a4877@24g2000yqm.googlegroups.com...

> 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??

 

[j]

On Jul 29, 5:27 pm, "
<kenslo...@mvps.org> wrote:
> 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.

> >

> http://www.slovaktech.com

> "j" <Evgeny...@gmail.com> wrote in message

> news:e3670e3d-d5e6-4a18-9666-00701f0a4877@24g2000yqm.googlegroups.com...

>
> > 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.GetDedicatedFo­lderNameForUserID
> > (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??-



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??

 

[Ken Slovak - [MVP - Outlook]]

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.

"j" <Evgeny.Br@gmail.com> wrote in message

news:2334afd9-cc43-4678-819d-6b14fc0662b5@32g2000yqj.googlegroups.com...

<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??

 

[j]

On Jul 30, 4:16 pm, "
<kenslo...@mvps.org> wrote:
> 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.

> >

> http://www.slovaktech.com

> "j" <Evgeny...@gmail.com> wrote in message

> news:2334afd9-cc43-4678-819d-6b14fc0662b5@32g2000yqj.googlegroups.com...
> <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??

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.

 

[Ken Slovak - [MVP - Outlook]]

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.

"j" <Evgeny.Br@gmail.com> wrote in message

news:4343ea03-0ccc-4241-b25f-3449c7d013aa@o15g2000yqm.googlegroups.com...

<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.

 

[j]

On Jul 30, 4:57 pm, "
<kenslo...@mvps.org> wrote:
> 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.

> >

> http://www.slovaktech.com

> "j" <Evgeny...@gmail.com> wrote in message

> news:4343ea03-0ccc-4241-b25f-3449c7d013aa@o15g2000yqm.googlegroups.com...
> <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.

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.

 

[Ken Slovak - [MVP - Outlook]]

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

"j" <Evgeny.Br@gmail.com> wrote in message

news:71cdb8c4-6aac-4cc1-94cd-8da3ba331b7a@g31g2000yqc.googlegroups.com...

<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.

 

[j]

On Jul 30, 6:32 pm, "
<kenslo...@mvps.org> wrote:
> 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
> >

> http://www.slovaktech.com

> "j" <Evgeny...@gmail.com> wrote in message

> news:71cdb8c4-6aac-4cc1-94cd-8da3ba331b7a@g31g2000yqc.googlegroups.com...
> <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

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.

 

[Ken Slovak - [MVP - Outlook]]

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.

"j" <Evgeny.Br@gmail.com> wrote in message

news:7927aa1a-3b4c-4e98-b6b8-416f02d84d0d@v20g2000yqm.googlegroups.com...

<snip
Mmmmmm...


> If you need a call from a background thread then do so after synching your

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.

 

[j]

On Jul 30, 11:24 pm, "
<kenslo...@mvps.org> wrote:
> 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.

> >

> http://www.slovaktech.com

> "j" <Evgeny...@gmail.com> wrote in message

> news:7927aa1a-3b4c-4e98-b6b8-416f02d84d0d@v20g2000yqm.googlegroups.com...
> <snip
> Mmmmmm...
>
> >If you need a call from a background thread then do so after synching your

> 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.

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??

 

[Ken Slovak - [MVP - Outlook]]

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.

"j" <Evgeny.Br@gmail.com> wrote in message

news:137ca1ed-1597-4ebb-a941-779ba51fda16@26g2000yqk.googlegroups.com...

<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??