7

I use lync Sdk to dock Lync conversation within my own wfp application. The problem is that when I try to dock the conversation like this:

public void Dock(Conversation conversation, IntPtr host)
{
  try
  {
    ConversationWindow window = _automation.GetConversationWindow(conversation);
    if (window.State == ConversationWindowState.Initialized)
    {
      window.Dock(host);
    }
  }
  catch (Exception ex)
  {
  }
}

sometime the window.State change between the verification and the docking and on windows 8 the generated exception seems to be not catchable and cause my application to crash where on windows 7 the exception is just catch.

the exception is of type Microsoft.Lync.Model.NotInitializedException

user1098580
  • 409
  • 4
  • 9
  • Can you catch the exception using the Application (App.cs) DispatcherUnhandledException event ? – PBelanger Dec 09 '13 at 21:05
  • No I already capture Unhandled exception with the OnDispatcherUnhandledException but it seems like no exception is raised at all and the app just crash. – user1098580 Dec 09 '13 at 21:12
  • Can you post the call stack of the thread throwing the exception? If it is not on the dispatcher thread, and the thread is not started by you, you may have to catch it at the `AppDomain` level. – Mitch Dec 28 '13 at 22:45
  • 1
    Use a disassembler and look at the definition of that exception to see if it inherits from Exception. Microsoft has a habit of not following the rules they tell us to follow. For example, catching SQL exceptions often requires catching a base sql exception class or you will never catch them. You can also explicitely catch that exception type – SASS_Shooter Jan 03 '14 at 19:37
  • Yes I tried to catch the error explicitly and it does not work in this case. Sorry for my late answer. I'll try to use a disassembler like you've suggested. thanks. – user1098580 Jan 15 '14 at 14:09

2 Answers2

0

I've found that Lync can be very finnicky about which thread it performs operations on. Some of the strangest behavior we've seen is when calls are expected to be made on the thread that created the conference/conversation and are called on another thread instead. Not seeing exceptions was definitely one of the oddities in these scenarios.

If I were you I'd dedicate a thread to performing Lync operations and poke these operations into it where needed (maybe with any callbacks to make the interface nice and clean).

If you just want to check that threading is your issue you could always dispatch these calls onto the WPF dispatcher to confirm (once confirmed you'll need to have your own threading model if you don't want to lock up the UI)

JRoughan
  • 1,635
  • 12
  • 32
0

No answer, but a suggestion. You might also try posting your question here:

Lync Client Developer Forum

If your issue is a bug it will get the attention of the product team. If not, there is also the possibility your question gets answered and problem solved.

user3076137
  • 111
  • 3