There are two versions of WebBrowser control (WinForms and WPF). WPF version supports touch and multitouch gestures. Does WinForms version of WebBrowser embedded in WPF application with WindowsFormsHost support touch and multi-touch gestures?
Yes the WebBrowserControl regardless of how it is hosted. It will still get touch and multi-touch gestures as long as its the only thing getting the input and the touch is from a recognised touch device to Windows.
Note you can't quite hook into this nor can you touch outside and inside the WebBrowserControl as it runs in a different context similar to running in a different window
Also for what its worth the underlying ActiveX Host is just running an Internet Explorer frame. If you have IE8 or more recent (such as assuming windows 7 or 8 for you?) it will run it in IE7 Compatibility mode too.
Related
I'm working on implementing native Windows touch support in a legacy WinForms app for .NET 4.0+. The app is being developed in VS 2013, and the main test system is Win 8.1 Pro. Doing this in a custom control, which is a descendant of the Control class.
According to the Windows Touch Gestures Overview MSDN article, "the default gesture handler maps some gestures to Windows messages that were used in previous versions of Windows" (see the 'Legacy Support' subsection). However, in my tests the basic pan gesture one can use to scroll a control in the vertical direction using one finger, isn't translated to WM_VSCROLL. The protected OnMouseWheel method isn't also raised.
Have I missed any important settings or anything else we need to turn on to enable this default mapping for the basic touch gestures?
I have test it on windows 10. Window without WS_VSCROLL style will not receive the legacy WM_VSCROLL for touch pan gesture.
You need to translate itself, but it is very simple. Handle WM_GESTURE in your custom control's wndproc and translate the GID_PAN action to WM_VSCROLL should do the work.
At my internship was requested that I'd look into utilizing the Windows OSK (win 7/8) for a touch dual browser.
After my experiences with the WPF webbrowser and extended research, I doubt this'll work. So do any of you know a way to...
1: Get an upside-down webbrowser component, with the same features as the standard IE webbrowser? (downloading, plugins, touch navigation) (And yes I've tried awesomium, only to find that it falls short)
2: Get an OSK, which can be turned upside-down, that supports as many languages as the windows OSK?
It needs to be in WPF or another C# based language that offers component rotation.
Thanks either way.
I have been looking but have been unable to find as yet a nice comparison of the differences in touch / gesture support between the Windows Store app API's and WPF.
I have seen that WPF includes some basic touch events but do the WPF controls handle gestures such as swipe, hold and tap or would we need to implement our own identification of these getsures using the basic touch events?
Thanks
Gavin
Here is the full list of Windows Store App controls:
wpf controls
When developing a Windows Store App, you will use there controls. They have (where applicable) built in gesture support.
I am trying to create a multitouch application.
I have the hardware which will allow me to do this. On the software side I want to be able to have WPF textboxes, WPF web browsers, multiple focuses, multiple keyboards and multiple users at the same time.
From what I've seen, I can't be focused on two controls at the same time.
What is the Microsoft MultiTouch approach for this kind of job ?
The OS limitations are what they are (and don't appear to change in Win8): only one hWnd at a time can have focus.
Since you are using WPF though, everything within your application (with the exception of the WebBrowser control ActiveX widgets you may be using) is rendered within one big hWnd.
WPF 4 introduced native support for multitouch, including multi-touch capture. The APIs for this are many but pretty intuitive so I'll just say this... go to http://msdn.microsoft.com/en-us/library/ms590078.aspx and search within the page for all of the members with "Touch" in their name.
The catch however is that the controls shipping with WPF 4 don't work with the touch input events... you'll only be able to interact with one of those controls at a time. To take advantage of the multi-touch capture APIs, you'll have to create controls that are designed with it in mind. Fortunately, the Surface team at Microsoft has you covered on that... the "Surface 2.0 SDK" includes a suite of controls (usable on any Win7 machine, not just for Surface) that were built with this stuff in mind.
To create application with MultiTouch UI, use MultiTouch Framework in .Net
Go to http://multitouchvista.codeplex.com/
I have developed a GUI for a random application using WPF. I have a bunch of out of box WPF controls laid on the application window. I haven't customized anything, didn't use bitmaps, etc.
When running my application and zooming using Magnifier application in Windows 7 (Win key + Plus key, the magnified GUI is showing pixels.I am probably wrong, because I can't explain it otherwise, but isn't WPF supposed to provide vector like control rendering?
Thanks for participating in the discussion.
Bonus Reading
Tim Sneath: Magnifier: An Interesting Discovery (archive)
WPF Vector based interface *(screenshot of WPF being vector scaled by Magnifier)
MSDN Blogs: Greg Schechter explains why it longer happens (archive)
Back when Vista first shipped, and when WPF was on version 3.0, zooming with the built-in magnifier would actually do vector-based scaling.
This stopped working when WPF 3.5 service pack 1 shipped. (It worked in 3.5 before sp1.) The reason it worked before then is that the DWM (Desktop Window Manager) - the part of Windows responsible for presenting everything you see on screen - uses MILCORE.DLL to do its rendering. Version 3.0 and 3.5 of WPF also used this same component to render - this meant that all WPF content was native content, so to speak. (In fact, on Windows XP, which doesn't have the DWM, MILCORE.DLL is something that WPF puts on your system for its own benefit. But it's built into Vista and Windows 7.) When WPF was using MILCORE.DLL to render on Vista, any effects applied by the DWM such as scaling would also apply in the way you want to WPF - it really did scale without pixelating.
Unfortunately, this is no longer the case. And the reason is that WPF started adding new rendering features. In 3.5 sp1, the new feature in question was support for custom pixel shaders. To enable that, Microsoft had to release an update to the MIL. (The Media Integration Layer - the bit that does the actual rendering.) However, they weren't really in a position to update MILCORE.DLL, because that's part of Windows - it's how everything you see on screen gets to be on screen. Releasing a new version of MILCORE.DLL effectively means pushing out an update to Windows. The release schedule for Windows is independent of that for .NET, and so the only way the WPF team could reasonably add new features was to ship a new MIL. (In theory they could have done it via Windows Update, but since WPF is now owned by a different division of Microsoft than Windows, that sort of thing doesn't seem to happen in practice.)
As of .NET 3.5 sp1, the MIL is in a different DLL called wpf_gfx_vXXXX.dll where vXXXX is the version number. In .NET 4.0, it's wpf_gfx_v0400.dll.
The upside is that WPF gets to add new rendering features with each new version, without needing Windows itself to be updated. The downside is that WPF's rendering is no longer as tightly integrated with Windows as it was briefly back when Vista shipped. And the upshot is, as you've seen, that magnifying is not as much fun as it used to be.
The magnifier application implements its own zoomed image rendering, so that's why you are seeing pixels. WPF does use vector graphics, but in this situation it's not the WPF application itself that is rendering the zoomed image.
If you use something like Snoop you can see zoomed and scaled WPF vector graphics rendering in action.
I suppose, Windows 7 magnifier takes a snapshot of actual application on-screen UI, and then magnifies it itself (not making a special case for WPF applications). Of course what it can access is just the pixels, not the vector graphics which works behind the scene.
The Windows-7-Magnifier is pixel based, but there is a difference in magnifier mode depending on wether an Aero-theme is active or not.
with Areo theme the zoom is pixelated.
without Areo theme the zoom is smoothed (blurry).
Only with Areo theme other Views (except "Docked") are selectable.