Im writing an application that needs to get notified when a control in another application is clicked\invoked. How can i catch the click from my application?
Here are some more related questions :
Is UIAutomation can be a solution? is it working on unmanaged applications also?
Is the Spy++ solution works also on managed applications?
i'll be happy with any help.
You need to use Global Hooks, but in managed apps you can only set up Global Hooks for keyboard and mouse events. So you will need to write an unmanaged app to do this.
Here's a blog post where a MS guy discusses the internals of Spy++ which might be useful:
http://blogs.msdn.com/vcblog/archive/2007/01/16/spy-internals.aspx
Related
I'm trying to find a good resource to get started with UIAutomation. I need to simulate mouse input in a WPF application. Are there any good examples out there? I couldn't find any, and the MSDN documentation seems too extensive.
UI Automation is not really intended to simulate mouse clicks. It is meant to expose the user interface in a programmatically-accessible fashion.
It organizes controls in a hierarchy that can be easily traversed/navigated by screen readers or similar applications. And, it uses control patterns to allow users to interact with the controls.
A Button for example can expose the InvokePattern via it's automation peer. You can simulate a click using the Invoke method on that pattern. This is done independently of the mouse, so there would be no mouse over/enter/leave/down events, just a Click event.
You can use mouse class with UIAutomation. But as CodeNaked rightly said, we should use UIAutomation patterns for mouse like operations and it is not good practice to use mouse class.
You can refer this code project article to start with UIAutomation.
I hope this will help you.
Hi Every Body
Am Working With WPF Application
I Needed To Use MS Reports In My Application So I Used WindowsFormsHost
But The Problem Is That The WindowsFormsHost Can'nt Handle Touch Events
How I Can Handle Touch Events In My Report In WindowsFormsHost
Please I Need Ur Help
Thanks
The question is as old as multi touch. As long as the control doesn't support it, you have to trick. Whether that's going to work depends on the control. The BING map control was successfully made to respond to touches. I think there's a touch enabled layer that takes touches and translates them to window messages. This can get a real mess.
Please keep in mind, that even if you can get such a solution to work, you won't get a touch optimized control. The control will probably have a bad, bad user experience...
If it's all about displaying data, I've described a possible alternative implementation on my post: for answer How to display a PDF document in a Microsoft Surface application?
the question is....
The application maybe in Silverligth.
It's possible to implement SYNChonous WebService call?
I try to realize any application RIA, with Grids, Edits and using WebServices in SL, but I do not understand how to make it's possible without a SYNC calls.
And I also need to use MODAL DIALOGS for some tasks.
I investigated the work of Daniel Vaughan who manages to run Web service calls synchronously, within a ThreadPool, but How I can do that GUI, wait for calls to webservices?
Daniel Vaughan Web: http://danielvaughan.orpius.com/post/Synchronous-Web-Service-Calls-with-Silverlight-2.aspx
Combining these basic things for other languages, IMHO is possible to build true application.
Hear suggestions...
Cheva.
Its best to analyse the actual objective which, since you want to do this in the GUI, is to prevent user activity until approriate resources have been fetched or processed.
One way to acheive that goal would be to have a synchronous call but the would just lock the UI up in a user unfriendly way. What we realy want is to lock the UI up but in an informative way. In fact we want the UI thread free to display such "Please wait I'm busy processing your request" preferable in a rich UI manner (some animation or progress going on).
To that you can use the BusyIndicator control (inside which you place all or just part of your current UI). You'll find the BusyIndicator in the Silverligt Toolkit. If you are using VS2010 and Silverlight 4 a Similar control is now part of the Ria Services SDK and can is called Activity.
Now when you want to do something "synchronous" you set the BusyIndicator.IsBusy property to true (in SL4 you set the Activity.IsActive to true). Then make a asynchronous request, on completion of the request you set the property to false.
For better or for worse, Silverlight doesn't support synchronous calls to web services. Your best bet is to go with something similar to what Anthony proposed in order to get the desired end result in your UI without actually locking up the UI thread.
So I'm planning on writing an application that is largely a windowless application. There will be windows for user interaction, but only at the request of the user. Otherwise the application sits in the system tray and runs a timer, executing some logic every minute or so. My question is this: As far as I can tell, I would put all the related logic in App.xaml.cs (starting the timer, executing the logic at each interval), but for some reason this seems wrong to me.
The app will have a system tray icon that users can interact with to get details, adjust settings, etc., but otherwise the app just sits there and does what it does. Is it appropriate to put all the code in the code-behind for the App.xaml class? I don't know why, but it seems as if I shouldn't, and there should be somewhere else, but I can't really think of anything.
I've never written an app like this before, hence my ignorance. Any advice would be greatly appreciated. Thanks.
James
Even with applications where most interaction is done through windows it's usually a bad idea to put all the code in the code behind. Interactions are often initiated eventhandlers in the code behind but you can put your code in classes you create yourself.
The same goes for applications that do not show a user interface most of the time. Most of the actions will be initiated from the App.xaml.cs but that doesn't mean all the code has to live there. You can encapsulate timers in their own classes that can kick off other code to do work for example. Divide your code up along lines of responsibilities, a window class does UI stuff, domain logic goes into other files etc. That will enable you to create more maintainable applications.
It doesn't sound like the code belongs there, and at most just a call to start the timers.
What does sound like a perfect fit for your issues, is the M-V-VM (Model - View - ViewModel) pattern. As you noteded, it also will 'feel' more correct then attaching logic to your code behind. Using MVVM you can separate your sparse UI into a View, and your code can exist separately in the Model and ViewModel.
I would recomend using the toolkit here, as it also contains good overview documents and a sample you can digest as you create your own solution. Laurent Bugnion has also released a MVVM starter toolkit that you could use to get started.
Also, here is some good stuff to get you started on actually setting up your controls in the system tray.
When using silverlight in a browser is there anyway to switch xaml pages? I'm also wondering how to go about using my encryption class I've wrote in c# to validate users in silverlight. Any help would be much appreciate!
If you're using Silverlight 3 Beta then what you're looking for is the Navigation system using the Frame and Page controls. There are lots of tutorials available online for this.
In Silverlight 2 the easiest solution is to replace the RootVisual with a Panel (like Grid or Canvas) and have your own code to switch the child elements (which are usually your own UserControls).
There's a good tutorial available at Flawless Code
We are using Jesse Liberty's method of doing the page switching in SL2. It is explained here. Jesse Liberty SL2 page switching
It also look or feels a lot like how SL3 does it with the Navigation mentioned above.
Caution: If you do this, the back button on the browser will need to be handled - users will exit out of your SL2 app when hitting the back button. SL3 has built in support for handling and responding correctly to the back button.