This is crossposted from this Lync forum.
Has anyone succeeded in docking the conversation window that appears for
an incoming telephone call ? Automation.GetConversationWindow returns the wrong window for incoming AV calls
This code:
Automation automation = LyncClient.GetAutomation();
ConversationWindow w = automation.GetConversationWindow(conversation);
works well for outgoing audio conversations (telephone calls), and acting on the resulting window indeed affects the onscreen conversation window.
More precisely, the first time it is called, the window is still unmapped on screen, then it gets mapped, has width and height, and responds to events. This can be checked by repeating GetConversationWindow and tracing the window's attributes.
However, for incoming calls (where the conversation window was already visible) GetConversationWindow still returns an unmapped window, no width, no height, not responding to events. As if it didn't find the existing window, and created a new one that will never come to life.
Of course I have googled several hours before asking the question. No existing docking example I tried worked for incoming telephone calls.
I am aware of this one (I have no right to make it a link, what's the rational behind this restriction?)
http://stackoverflow.com/questions/13541338/not-able-to-capture-needssize-change-event-for-lync-conversation-window
The closest subject I came by was:
which hints at the conversation window being right only when the toaster has closed. But I tried such "late docking" (with a "dock" button that should start docking at the time I choose) and it failed, too.
If everything else fails I can try to use AutoHotKey for that, idea given by
https://social.technet.microsoft.com/Forums/en-US/ee13ce5c-c442-4ec7-bdeb-d228de64f3d2/default-to-compact-view?forum=lyncvoice (sorry, not the right to make it a link, either)
but keeping to .NET framework would be better.
