1

I'm having some troubles using the Lync2013 Client SDK. It is a minor thing, but in my mind it should just work.

I'm creating an application which displays some data of the caller, using the ExtensibilityWindow. On application startup i register the application etc and on an accepted call, the program calls BeginOpenExtensibilityWindow on the ConversationWindow. This works fine in almost all of the cases. However, for as i can tell now, there's one specific scenario when this does NOT work: When a new incoming AV call presents, while having an active (onHold or not doesn't matter) incoming call.

(So caller A calls me, i accept and while on the call, caller B calls me. Then the function BeginOpenExtensibilityWindow does nothing at all)

If one of them is outbound, there's no problem, but when both are inbound, the call to BeginOpenExtensibilityWindow passes without doing anything. EndOpenExtensibilityWindow does NOT raises any error, it just passes.

To find out what the problem could be i tried the following:

  • No caching of the retrieved ConversationWindow: Everytime i need it, i call Automation.GetConversationWindow(conversation)

  • Delayed call to BeginOpenExtensibilityWindow: Starting a background thread, wait for 5 sec after connected and then call it.

  • Calling CloseExtensibilityWindow before BeginOpenExtensibilityWindow

What i found was: The first conversation raises an error when calling CloseExtensibilityWindow before BeginOpenExtensibilityWindow. The second however does NOT, instead, calling CloseExtensibilityWindow closes the extensibility window of the first conversation!!! Im absolutely 100% sure i'm retrieving the reference to the second window by calling automation.GetConversationWindow(_conversation), with the '_conversation' being the second call!

So to be absolutely sure, i logged every call to the window, like so:

 internal ConversationWindow ConversationWindow
    {
        get
        {
            _window = _automation.GetConversationWindow(_conversation);
            debugA.Add(string.Format("ConvId: {0}, WinHandle: {1}", _conversation.Properties[Microsoft.Lync.Model.Conversation.ConversationProperty.Id], _window.Handle));
            return _window;
        }
}

With debugA being a static List,

Ofcourse, sigh..., the conversationId was empty all the time (the root of the problem??) So i switched it to _conversation.GetHashCode(), then the contents of debugA was:

ConvId: 21950498, WinHandle: 1902160

...some more of that...

ConvId: 13391695, WinHandle: 1902160

...some more of that...

Clearly the automation is returning the same handle for different conversations! Again, this is only on two incoming AV calls, IM's work fine and have no mixed-up references.

It seems to me like a bug... But im no expert....

Any help, greatly appreciated!

user1515791
  • 675
  • 4
  • 20

1 Answers1

0

Forgot to mention, it was a bug and Microsoft fixed it: September 8, 2015 security update (KB3085500) for Lync 2013 (Skype for Business)

user1515791
  • 675
  • 4
  • 20