Working on a WPF application that integrates with the Lync Client, but does not replace the Lync Client or use UISupression.
When a call comes in the user can answer the call via our application using Click or Function key. The problem is that after answering the call Lync generates a conversation window which steals focus away from our application. This is a problem because any function keys the user might press (to put the call on hold for example) will go to the Lync Conversation window, not to this application.
I've seen this Microsoft article that allows you to get conversation windows and dock them, which seems like a viable solution, except that our application really doesn't have room to host those windows.
What can we do to prevent or work around this problem where the Lync Client Conversation windows steal focus from our application?
I'd say docking is definitely the way to go. You could create a form as part of your application, but separate from your main application UI, to dock the conversation window into. You could give this a single pixel border, or hide the border totally, so the Lync conversation window won't look as if it's docked - the user shouldn't notice any difference between the docked and non-docked window. The benefit to this approach being, you don't need to dedicate any of your main application's UI real estate to hosting a conversation window.
One thing to be aware of - if you're using Lync 2013, a potential problem with this approach is that docking a conversation window pulls it out of the tabbed conversation view - but this might not be a problem if you're only dealing with Audio calls as these get pulled out of the tabbed conversation view by default.
It would seem you are unable to do this according to MSDN
http://social.msdn.microsoft.com/Forums/lync/en-US/06db0465-6a86-4afb-8f0a-a5299d92a349/how-to-suppress-opening-the-lync-conversation-window?forum=communicatorsdk
Without using the UI Suppression Command
Given that the conversation window is a problem: "Lync generates a conversation window which steals focus " - consider creating your own conversation window, as described here:
Building Lync IM Conversation Windows
This is a bit of a hack, but you could just move the ConversationWindow outside the boundaries of the screen.
Assuming multiple monitors,
Screen[] screenArray;
screenArray = Screen.AllScreens;
cw = LyncClient.GetAutomation().GetConversationWindow(lyncConversation);
cw.Move((screenArray[0].Bounds.Left - cw.Width), (screenArray[0].Bounds.Top - cw.Height));
For the focus problem, don't initialize the application until the movement above is done and you should be fine.
Related
Well, the project has moved along rather nicely and we have a pretty darn good product, but a wrench has been thrown into the gear works.
We have a C# 2012 application that interacts with another application (written in VB 6 of all things) and we can do a good bit with it so far, but we have a problem.
We need to select a button on a toolbar at the top of this particular application's window, but the button is not available through an API search. We have the main window's handle and can see all of its children, but I think the Toolbar is a User type control that we can't access through the API Calls. This application is very poorly designed and we had to do a LOT of work just to discover TWO User ID text boxes on the logon screen.
Anyway, my question is this: How would I set up a call to the main window and click a certain X, Y coordinate of that window's viewable area? I am using SendMessage to send mouse clicks to press a button control already, but if I can't get access to that button control, the idea was to send mouse clicks to a specific coordinate of the window.
Any ideas folks? Thanks!
It looks like the solution will be to get the Window's rectangle and add the offset in order to use the mouse event API call.
Thank you to #Idle_Mind for the suggestion. It is at least working on our test environment. It will be next week before we can test the solution out in our client's environment.
I am working with Lync 2013 SDK and WPF in a way to add a toolbar to the Lync conversation window.
I did dock the Lync conversation window in a panel inside a WindowFormHost pretty much following this tutorial http://msdn.microsoft.com/en-us/library/lync/jj933086.aspx.
Now I can add my custom functionnality inside my WPF window.
The problem is that docking the conversation causes all Lync conversation window shortcuts to act in a strange way. By default, they don't work anymore, even if I try to focus the docked conversation window, they still don't work but when I focus a control of this window they start working all over again.
I need them working whatever is focused on in my WPF window or the docked Lync conversation window.
I tried to use some user32.dll functions to invoke those shortcuts using the conversation window handle IntPtr, but it did not work.
I also tried to use
SetForegroundWindow(_automation.GetConversationWindow(convertion).Handle)
and then use
SendKeys.SendWait(keys)
but it only work when the conversation is not docked.
We had this issue in a project I was working on. I think the problem was that the shortcuts were being unregistered when the window was out of focus. We had to re-register the shortcuts that were related to that window. I'm not sure how your shortcuts are registered though.
I have a Silverlight control containing an image. I want the user to be able to drag the image out of the Silverlight application and drop it anywhere they would be able to drop an image. For example, to the Desktop or to a PowerPoint slide or Word document. Everything that I have read thus far says it cannot be done but I find that hard to believe. I'm very new to Silverlight and RIA development so any help would be much appreciated.
Below is the code sample in my WinForm Form but the drag never starts.
string[] aString = { imagePath };
DataObject data = new DataObject(DataFormats.FileDrop, aString);
data.SetData(DataFormats.StringFormat, imagePath);
DoDragDrop(data, DragDropEffects.Copy);
Well the trouble is that a drag operation in Silverlight doesn't have simple access to anything outside the browser (by design). Depending on the user's settings you even have to get explicit permission for clipboard operations and sandboxed temporary file storage. This really sounds like a task better suited to a WPF application (perhaps with web deployment?) or some other desktop application technology.
However, that being said here are some things you could try/consider:
Silverlight/Javascript/ActiveX combination hosted in Internet Explorer
Silverlight 5 "Out of Brower" & P/Invoke (I heard P/Invoke will be supported when Silverlight 5 comes out)
Silverlight connecting to a web service running on the same computer (crazy, but you didn't ask for "not crazy", you asked for possible)
I am not very familiar with drag and drop in the Win32 API so it would take a lot of research and experimentation before I could confirm that this was even possible (and I can already tell you it isn't practical).
Edit: Based on the extra information you provided about the question I suspect it is possible to do what you are attempting. First, are you using WPF or WinForms? I assume WPF but one of your comments says WinForms. I wasn't very familiar with WPF drag/drop operations, but having looked into it, I think your code is on the right path. I created a WPF application and initiated a drag during a KeyDown event. This meant that the mouse button was not necessarily pressed. If I initiated the DragDrop while the button was down it worked. If I initiated while the mouse button wasn't down, I had to push the mouse button down and the drag operation would start (this was unexpected since I assumed the mouse would have to already be down). If I pressed the mouse down outside the application, then gave the WPF app focus (ALT+Tab), then initiated the DragDrop while the mouse button was still down, it didn't work. I got a reference to the MouseDevice and checked the LeftButton property, and the state was showing as "Released" even though the button was still being held down. It seems the key here is the way drag/drop interacts with internal mouse state. You might have to find a way to set the mouse state (maybe with the UI Automation API?). At this point it should be painfully obvious that this whole thing is a hack (even though it is probably possible to get it to work somehow).
The solution we came up with was as follows. The RIA i.e. Silverlight sends a message to our Desktop application WinForms with the path of the image to drag along with the bounding rectangle in screen coordinates that we want to start the drag from. The Desktop code creates and places a Panel over the area that we want to drag from. This panel is where we use DoDragDrop to initiate the native drag when the user left clicks. Since this panel is placed outside and above the silverlight control, everything works perfect. Sandbox defeated.
I have been working on some Silverlight apps for the past few months and fully investigated your exact requirements only to find it was not possible. I believe you can drag from the file system, from Silverlight control to control, but not to the file system.
Does Silverlight 4 support drag and drop from app to desktop?
http://msdn.microsoft.com/en-us/library/dd772166%28v=vs.95%29.aspx
I am trying to create a parent WPF/surface application which will host multiple WPF/surface applications. I am looking for some pointers of how to implement such functionality. Was reading http://msdn.microsoft.com/en-us/library/ms742522.aspx but it talks about hosting Win32 content in WPF and vice versa.
My idea is to have something similar to MDI forms where you have a main form and you can instantiate multiple child forms.
In my case, these would be different applications which will be launched using a config file and loaded within the main application.
Also, since is there a way to ensure that the main window's process memory is not hogged by the child process initiated.
Edit:
The host application will launch different applications based on what user selects. One can say its like an application launcher which are build on WPF/Surface touch SDK. Now once the application is launched the launcher goes in the background(except showing small button to bring it forward again at some point later) and when the user ends the current application launcher comes back again in foreground. The only interaction i feel which is necessary is knowing the launched application is terminated or invoking applications in a limited screen area. If someone has seen the Microsoft surface application launcher, even when the application is launched there are corner buttons which bring the app launcher to foreground.
I would first look at using Microsoft Prism, specifically the Modularity namespace.
Except for the "different applications" part, it sounds like a classic case for MVVM. Are these "different applications" actually separate applications, or could they simply be separate projects within the same application? That may simplify the choice of presentation.
I suppose you could still have a View called "Host" that presents a different app.
Of course, WPF doesn't have the concept of MDI, but you can open multiple, non-modal windows.
It really depends on what you mean by "hosting". Does the main window need to somehow handle and/or interact with the other applications, or is it just a launching pad for other applications?
I followed this approach to solve this problem. The launcher was not hosting the application within itself but would launch a new application and hide itself.
Steps I followed:
The main launcher application will run in Kiosk mode i.e always on top/no option to close by capturing the close event/No instance shown in taskbar/no title bar/killing the explorer.exe/hiding the taskbar.
The launcher populates a horizontal listbox (data templated for UI) which lets occupied main center area of screen and can be scrolled either ways.
When user selected an item on listbox, click/tap event a separate process is launched with launcher window's visibility set to hidden and a small button(basically a window with just a button inside and size set to height/width of button) created on the either corner of the screen with always on top option.
The functionality of button is to minimize the current working application and set visibility of launcher back to visible and setting the focus to this window.
Since the process is launched by launcher, i trap the close event for the launched window to know user ended the application and then again pop up the launcher back.
When I set focus on a text box, on a forms load event in Windows Mobile 5.0, the Windows tool bar appears even though my form is maximized.
When I do not set the focus on the text box the form opens maximized. I do not want the windows tool bar appearing.
How do I prevent this from happening?
TThe start bar in WinMo is actually not part of your app - it is a separate process managed by the Shell and it really wants to always be on top. Trying to get your app above it goes against the design goals of WinMo (though it's a common thing to want to do).
I'd recommend doing some searching and reading on "kiosk mode" to garner what knowledge you can from others who have been down this road, but what you're seeing is that the StartBar is getting set topmost.
Raffaelle Limosani has a pretty decent blog entry that covers kiosk mode, so it's a good place to start (take a look at the other blogs he links to as well).
The toolbar at the top is actually a separate window, and it has a habit of appearing when not wanted over top of a full-screen ("kiosk" mode) app. For example, if you ShowDialog a second full-screen window from the first, the Start window flickers up for a split second before going away.
The only way I ever found of dealing with it was to hack into the API and actually make the Start window hidden while my application was open. This is a big potential problem, because if your app crashes without making the Start window visible again, it will stay invisible until you reset the device (or run you app again successfully).
I'd advice against doing this unless you absolutely have to. As ctacke points out, this would be an example of an app not playing nicely with Windows Mobile.