I looked at this thread here searching for a Web Browser to embed into a touch-enabled WPF application (on Windows 8 or 10).
I need to support manipulations (meaning be able to zoom, pane, rotate with touch events).
If possible, I would like also to support one of the game frameworks being either Adobe Flash, Unity or Web GL. Or a really working HTML 5 support with touch events.
Investigations performed so far:
- I have tried Awesomium, but I have too many issues with it. I created two questions on their forums two months ago and still don't have any reply.
Also, I tried CEF, but it crashes when the main application is stopped. Also, it does NOT support touch events.
Obviously, I also tried the default WebBrowser, but this one is an ActiveX control so it does not support manipulations.
So, I am about to test dotnetbrowser and EO.WebBrowser. Both require licenses which is less attractive to me but anyway if this the only way to go.
However, none of these browser implementations describe if they support a touch
interface.
Do you have any input on this issue?
Thanks a lot for your help
Best regards
Christophe
Finally I made it work by using a wrapper above CEF called Xilium.CEFGlue.
I could dive into the source code and add the touch support myself.
It works pretty well.
Thanks a lot for your help.
Christophe
Related
I'm developing a c# touch application for windows 8, desktop mode, and i'm unable to find the best approach to do it. My question is: Should I use the existent Windows 7 Touch API c# or there is a new multitouch c# API that can be used to develop windows 8 desktops apps?
I know that windows 8 have legacy support for the win7 touch api, just need some insight and feedback if still is the best and only way to do it.
Does anyone had a previous experience with this problem?
Edited: I found this article: http://software.intel.com/en-us/articles/touch-gestures , basically the UIElement exposes methods that enable touch manipulation. Maybe this is the way to go. Any thoughts?
Thank you.
Windows 8 API has a new API based on WM_POINTER message see http://msdn.microsoft.com/en-us/library/hh454916(v=vs.85).aspx
Windows 7 API has some drawbacks, see http://the-witness.net/news/2012/10/wm_touch-is-totally-bananas/
WM_TOUCHxxx messages are not prone to this problem:
http://social.msdn.microsoft.com/Forums/en-US/ce6d630a-b345-46ac-88ef-773704986d62/touch-responsiveness-issue-how-to-resolve-jagged-nonsmooth-lines?forum=winappswithcsharp
Both the WM_TOUCHxxx and WM_POINTERxxx message will be prone this this problem:
https://web.archive.org/web/20150709083602/https://connect.microsoft.com/VisualStudio/feedback/details/903760/wpf-touch-services-are-badly-broken
If your c# desktop application is using WPF, your only viable option is to implement your own TOUCHDEVICE that fixes these underlying issues, since it appears Microsoft has decided WPF touch is no longer important.
It depends on what actually are your needs in your app.
If you only want new fast ways to rotate and zoom objects, maybe the WPF Manipulation API is all you need.
If, however, you need to handle multiple fingers on your GUI independently, or in a custom way, you simply handle the usual OnTouchDown, OnTouchMove, and other events.
Please note that, however, multi-touch is only available from inside a single window. In other words: you can multi-touch two objects on the same window, but you won't be able to multi-touch two objects that reside on different windows. If you want multi-touch, multi-window funcionality, you need to:
Use .NET 4.7
Change some configuration in your WPF app
I'm writing an app (in C#) which as a part of it must simulate and send some key strokes to another application. I'm using http://inputsimulator.codeplex.com/ project for simulating keys, and it works in many applications, but in some it doesn't - i.e. Mortal Combat 4.
I've googled about it, and found many answers varying from 'it's impossible' to 'you must use XXX library' etc. Those answered scared me a lot, and even nearly convinced I'm not able to do it at that time, BUT...
M$ Virtual Keyboard works. It works in ALL applications. So it IS possible... Does anyone of you, clever guys, know how can I achieve this?
Ok, I think I finally got it to work. I used API Monitor recommended by Neal P and it showed just minimal differences between OSK calls and mine. A bit later I've tried to make my calling thread sleep some time between sending messages with press and release key and that was it.
Although you were able to achieve your purpose, the way you achieved it does not fundamentally answer your question: How to simulate keyboard input in ALL applications?
There's a bunch of situations where the common user mode Microsoft API already mentioned does not work, like game applications that use the DirectInput API or protected games.
I have built a library that can help in this situations, it provides a simple C API that internally communicates with device filter drivers. It is able to send input for DirectInput based games and also is able to bypass some game protections. I have checked and it is still able to bypass some known game protections by using the x64 version of the library. Game protections commonly hook only the x86 system's api. Well, at last now, 18 February 2012, this is what I'm seeing happening.
Take a look at SendKeys on MSDN
I'm currently working at a application that helps people understand how to do there job. You can see it as a personal coach that guides them trough all the steps they need to do that no normal person could keep remembering.
In my previous application we had the ability to show the user up to 4 pictures (what proves to be more then enough). The application would load the data and see how many pictures where in every instruction and then sort out the picture in the best fitting way without messing up the scale and resolution of the pictures. This all was done with GDI+ and worked very well.
Ofc, change is something that always happens, my bosses came up with some great ideas. So they want to be able to see movies on the screen, animated gif's, 3D models that can rotate or animate. So I think we had pushed GDI+ to it's limits and it's time to look for something different.
I have heard and readed about WPF but have no experience with it. Is it even possible to do all what I ask in WPF? And what about the old picture-merging thing I wrote, can we also get it done in wpf? I tried to make some things working but I didn't went as smooth as I hoped.
I'm also concerned about the fact that the interface needs to be dynamic, the one moment it should be showing picture with some text above it, the other moment it should be showing another text with a video under it.
I would love to hear some opinions here and if you got some other suggestions I should look into pls tell me. Thnx in advance
PS: If WPF is the choice, should I convince my boss to change to .net 4.0?
Although my answer can be termed subjective, I find WPF better than GDI+ anyday. You can do everything you can in WPF which you have done/could do in GDI+ (apart from pure games/game engines). If you can afford the steep learning curve of WPF, I think it will be better investment as this technology is not going anywhere soon.
As for .Net 4.0, WPF 4.0 does introduces some important functions in 4.0 (specially easing functions for animations) but there is nothing you cannot do without if you are using 3.5. I won't recommend 3.0 though mainly because of performance in animations.
WPF is up to the task, but you could also check other options.
You could go web based, and have either an XBAP (WPF in the browser), or Silverlight/Flash app.
Silverlight/Flash doesn't require that much from the client (to install), and is easily updatable, and both can do the job.
I'm trying to automate a hidden .NET application, with another .NET application (written in c#) using the easiest way possible. It's NOT for testing purposes, it's a way to fulfill the lack of scripting for this application.
I already tried white framework, but there is one major problems with it: the way it's working. It's slow and it's not working on hidden windows and controls (like the winAPI does). Whats more, when "clicking" white moves the mouse, brings it's targeted window to the front and so on.
I was also thinking about using a user32.dll wrapper, because the way it's handling it's target is what I need, but I've red it's not working with .NET applications. It also would be a problem working with it, because my targeted application got 5 button labeled "...", and would be really hard finding 2 of them I need. I also would like to use the controls .NET id (the name the developer gave to it's controls when designing the GUI).
BTW, my targeted application is MeGUI if that helps. We do a lot of video encoding and a tool like this would help us a lot. I need the MeGUI to be hidden, because I'm the only programmer, others using my tool shouldn't see what happens in the background, not to talk about the many windows popping all around.
You can add a reference to the exe from your project and then create an AppDomain to run its main method. From there, it should be possible to queue delegates to its main thread's loop. With a bit of reflection, you could have those delegates invoke the click events and whatnot directly.
I've never attempted this approach, but it should work.
You should try Stephens idea instead of scripting a hidden app. A .NET Windows Forms App (EXE) is still a .NET Assembly and that means you can use that the same way as a DLL, just add a reference and use the public classes.
If you still want to try some scripting, take a look on the "Microsoft UI Automation" API and the "System.Windows.Automation" namespace.
Nice article here: http://msdn.microsoft.com/en-us/magazine/cc163465.aspx
MSDN Doc: http://msdn.microsoft.com/en-us/library/system.windows.automation.aspx
I have a WPF app which contains a number of child controls.
One of these controls hosts a third party library which underneath the covers runs some native code which throws access violations and crashes the application. Unfortunately removing the library is not an option.
What I'd like to do is spin up a new windows process, host the third party library inside that, and somehow communicate with it. Much in the same way that Google Chrome and IE8 handle browser plugins.
The issue is that the third party library needs to draw to the screen, so I have to somehow have the equivalent of an HTML iframe inside my WPF app's main window.
I'm not sure how to get started on this, it's proving difficult to google for thus far. Any advice is greatly appreciated.
This is a tough one, but fortunately for you there is a little work being done in this space lately.
Have you heard of the System.Addin namespace in .NET 3.5? It could probably help in this case. It allows for controls to be loaded in a separate AppDomain, but be displayed in the same UI. I'd imagine you'd have to do a little bit of work to get everything communicating properly (never done this before), but it's possible.
Have a look at this early post from the Add-in team: http://blogs.msdn.com/clraddins/archive/2007/08/06/appdomain-isolated-wpf-add-ins-jesse-kaplan.aspx
Seems like they keep their samples and helper code on codeplex: http://clraddins.codeplex.com/
I'm very interested in this, so if you get this working, let us know how this went for you!
Coming in way late. If you still need this, have you seen this project: https://learn.microsoft.com/en-us/archive/blogs/changov/hosting-wpf-ui-cross-thread-and-cross-process
I'm running multiple plugins in multiple external processes in my LOB app. My framework grew out of the project above.
Probably not the easiest of tasks. Have you considered hosting your 3rd party stuff in a separate App-Domain? That way you will also get a good level of isolation while saving you the hassle of another project. Does it have to be refreshed constantly or could you refresh at predefined points in your application? Maybe some scheme where you basically do a screenshot of the 3rd party output and show it as image in your original app would then be possible...