On Jul 30, 4:16*pm, "Ken Slovak - [MVP - Outlook]"
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.

--
Ken Slovak
[MVP - Outlook]http://www.slovaktech.com
Author: Professional Programming Outlook 2007.
Reminder Manager, Extended Reminders, Attachment Options.http://www.slovaktech.com/products.htm

"j" wrote in message

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

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.

--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Professional Programming Outlook 2007.
Reminder Manager, Extended Reminders, Attachment Options.
http://www.slovaktech.com/products.htm


"j" wrote in message
...
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.

On Jul 30, 4:57*pm, "Ken Slovak - [MVP - Outlook]"
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.

--
Ken Slovak
[MVP - Outlook]http://www.slovaktech.com
Author: Professional Programming Outlook 2007.
Reminder Manager, Extended Reminders, Attachment Options.http://www.slovaktech.com/products.htm

"j" wrote in message

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

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

--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Professional Programming Outlook 2007.
Reminder Manager, Extended Reminders, Attachment Options.
http://www.slovaktech.com/products.htm


"j" wrote in message
...
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.

On Jul 30, 6:32*pm, "Ken Slovak - [MVP - Outlook]"
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

--
Ken Slovak
[MVP - Outlook]http://www.slovaktech.com
Author: Professional Programming Outlook 2007.
Reminder Manager, Extended Reminders, Attachment Options.http://www.slovaktech.com/products.htm

"j" wrote in message

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

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.

--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Professional Programming Outlook 2007.
Reminder Manager, Extended Reminders, Attachment Options.
http://www.slovaktech.com/products.htm


"j" wrote in message
...
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.

On Jul 30, 11:24*pm, "Ken Slovak - [MVP - Outlook]"
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.

--
Ken Slovak
[MVP - Outlook]http://www.slovaktech.com
Author: Professional Programming Outlook 2007.
Reminder Manager, Extended Reminders, Attachment Options.http://www.slovaktech.com/products.htm

"j" wrote in message

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

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.

--
Ken Slovak
[MVP - Outlook]
http://www.slovaktech.com
Author: Professional Programming Outlook 2007.
Reminder Manager, Extended Reminders, Attachment Options.
http://www.slovaktech.com/products.htm


"j" wrote in message
...
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??