WPF supports touch or multi-touch screen? - c#

I am wondering whether WPF on .Net 3.5 supports touch or multi-touch for laptop? Appreciate if there are some cool Demos to show the effect.
I am using VSTS2008 + C#.
thanks in advance,
George

WPF 4.0 Beta 2 supports full multi-touch, but only on Windows 7, as Windows 7 is the first multi-touch enabled Windows version.
For 3.5 on XP you can try out the Breeze for WPF 3.5 multi-touch framework at http://code.google.com/p/breezemultitouch/ its open source and plugs into TUIO (multi-touch protocol). TUIO allows you to bridge between various multi-touch devices and your WPF 3.5 application without the need for operating system multi-touch support.

It's not really WPF's responsibility to support touch-devices, but the O/S. The O/S simply delegates the events of mouseDown == fingerTouchedScreen to WPF (not a 100% accurate statement, but good enough :) ).
If you want to develop WPF for touchscreen-devices, you really need to look at your UI design instead of what's supported and what's not.
This post has a nice answer for that.
Basically, you work with the same events as you'd do with your standard smith'n'wesson point'n'click devices :)

Not natively, but check out the Windows 7 Code Pack, which brings 7-based features to .NET developers. This is code from MS, btw, not a 3rd party library.
It includes multitouch code, but I don't know exactly how easy it is to use in a WPF application.
Relevant links:
http://blogs.msdn.com/charlie/archive/2009/08/07/windows-7-code-pack-v-1-0-released.aspx
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=1c333f06-fadb-4d93-9c80-402621c600e7

There's some great sample code in the "Windows 7 Training Kit For Developers". Sure you'll need Windows 7, but it's totally worth it!
http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=1c333f06-fadb-4d93-9c80-402621c600e7

Related

Will WPF .Net 6.0 Applications work on Windows 7 or Windows XP?

I have to design a simple application to communication via serial ports with a machine and then record the responses in a excel file. The application needs to be able to work with window XP all the way up till windows 10. Is WPF .net 6.0 a good choice?
From what I see you will need to go back all the way to .NET Framework 4, if you really need to support XP. I have however never tested this, and you might still get it to work. If you only need Windows 7 and upwards, .NET 6 seems fine. The supported OS Versions of .NET Core can be found on GitHub. The supported Framework versions for each OS can be found in Microsofts Documentation.
Your specific needs seem to be serial port communication and excel file creation, both are compatible with .NET Framework 4.
You don't explain why you need a GUI, WPF will be a problem, but WinForms should be fine.
OP:
Will WPF .Net 6.0 Applications work on Windows 7 or Windows XP?
TL;DR: hardware-based Windows Desktop acceleration is not available on XP so there is no point trying to deploy WPF on it irrespective of what version of .NET you are trying to use
Windows XP support has ended
OP:
...needs to be able to work with window XP all the way up till...
Unless you are working for a major government body, support for Windows XP has ended, so no.
WPF requires hardware acceleration
Also, given that you are wanting to create a WPF app, a technology released late 2006, one of the biggest selling points of WPF historically was that it was one of the first MS GUI frameworks to support hardware-acceleration (apps were blitted to the screen in a single operation via DirectX) - something that didn't appear in the Windows Desktop until Windows Vista in early 2007 (remember suddenly people were buying 3D cards just to run Windows).
Unfortunately, Windows XP, an operating system released in 2001 predates hardware acceleration in the Windows Desktop, so even if you managed to deploy a WPF app on XP, it is unlikely that it will be hardware-accelerated and will run poorly.
Additionally, WPF was originally released in .NET Framework 3 and required one of Windows Vista, Windows Server 2008 R2 SP1+.
What's the minimum for WPF?
You can use WPF on Windows Vista+ with .NET Framework 3.0+ safe in the knowledge that it will benefit from hardware-acceleration.
What about the .NET 5+ road?
Given that WPF in .NET 5+ is Windows-only anyway (thus kinda defeating the mandate of cross-platform that is .NET Core/5+) and the fact that more and more Windows-specific technologies are either being dropped or not ported in the first place to .NET 5+, you really need to ask yourself:
Question
If I know my app is only for Windows and I don't care about cross-platform, should I start to use .NET 5+?
...to which the answer is a big "Be careful before signing up!".
The following technologies are not available in .NET 5+:
App Domains
CAS (including Security Transparency)
GAC
...which is a real shame since there are quite a few legacy WPF (and WinForms for that matter) Smart Client projects out there that require these technologies for bullet-proof extensivity and sandboxing of 3rd party plug-ins.
To me WPF .NET 5+ is a bit of an unknown; it is unclear if it is hardware-accelerated and even if it is, do you want to risk such support being dropped in the future (in exactly the same way AppDomain.CreateDomain was dropped in .NET 6).
My advice would be to stick with .NET Framework 3.0+ (.NET Framework 4.x+ would be better) if the intent is to create hardware-accelerated WPF apps.

Windows Phone Silverlight/Xaml Which one i choose for developing my application [duplicate]

When I create new Windows Phone project I have an option to create a "Windows Phone" or "Windows Phone Silverlight" app. I know that they have different runtimes and different APIs.
I was under the impression that Microsoft wants to unify Windows and Windows Phone platforms so why is there even a Silverlight version? What benefits does it bring?
Also, if I want to create an app just for Windows Phone and never have plans to bring it to Windows, what should I choose, Silverlight or Windows Phone?
I'd suggest you go with "Windows Phone" (non-Silverlight). It's the new API, which works for both Windows and Windows Phone. At some point you may want to port the app or create a new one for Windows and you'll already know the API (and porting will be way easier). Also, the new API will most likely get more updates and features added, and at some point you may even be forced to update to it (either because the old one is no longer supported, or because it does not have some features that you need).
As it was said in the other answers - the Silverlight option is there only for backward compatibility and is likely to be phased out in time. That is - it's good if you already know the API and have many libraries (yours or others) for WP Silverlight, but if you're just starting - you'd better go for the new technology.
Edit
There is one other thing to consider before choosing between the two types of apps. Some features are only available in a Silverlight app, and others (smaller amount) - only in a Xaml app. Here's an article with some info on the differences: Migrating your Windows Phone 8 app to a Windows Runtime XAML app
Windows RT Xaml is quite new and People have to generate some knowledge first.
Silverlight for phone has been around for years and there's a load of tools available: Phone Toolkit, diverse Controls, etc.
Just killing it off would have hurt many developers who built up intellectual property over a long time forcing them to start over.
When starting a project with Silverlight you will have more things around that help you get stuff done.
When starting with WinRT Xaml, you will have better performance, but will have to figure a lot out by yourself.
So the Silverlight option is there to not throw of Silverlight developers.
I recently started a new project on WinRT Xaml and my experience was that I had to recreate a lot of common tools like Caches, etc. But also a lot of things that were in Toolkits previously are now part of the platform itself. Also, when moving over to Windows 8, you get to share a lot of code which is nice.
Unifying the environment(s) would be ideal. In my opinion, it hasn't been very successful. At one point in time, you could only develop under Silverlight, so what you are seeing is just a newer version of the same thing to keep backwards compatibility as well as to keep Silverlight's developers happy. In the future, it will probably be phased out. Plus if you want to support older Phones, Silverlight is basically your only choice (you'll be surprise, how many WP users haven't updated their 8.0 to 8.1)
There really isn't any other real benefit of Silverlight other than maybe the Windows Phone Toolkit which has been tremendously useful (you can see how many SO's answers rely on this simple addon). Once the universal runtime gets fleshed out to the point where the documentation reflects what's actually available -- then I think it would be the default project for developing in Windows going forward.
If you're just starting, I would use Silverlight the knowledge based is much greater. After you get use to the WP environment then switch to runtime.

Cross platform apps with WPF

I'm thinking of developing a desktop app in C#. Although windows will be my main target, later I'll try and run the app in MacOS X and linux. Can I do this today, in a simple way?
I'm aware of the mono project, but it is not clear to me if I can do this in a simple way.
Also, what is the relation between WPF and Silverlight? AFAIK Silverlight follows a plugin model much like Flash or Java. Can I develop my desktop app with Silverlight and deploy it on windows, linux and os x without much changes?
Any pointers will be greatly appreciated.
The Mono project does not support .Net 3 and WPF yet, and it will probably been some time before that happens.
Silverlight might be sufficient for your needs.
As of Silverlight 3.0 you can run Silverlight outside the browser, even create a shortcut to it on the desktop.
Last I heard, the Mono project has no plans to implement WPF, however they are working on other .NET 3.5 features, especially LINQ and ASP.NET MVC. The problem with implementing WPF in Mono (beyond the size and complexity of the API) is that on Windows it uses DirectX for rendering, so an implementation for Mono would need to use OpenGL. Definitely not a trivial undertaking.
WPF is used to build desktop applications for Windows only. Currently no other platforms are supported. If cross-platform support is a must, you can create a browser-based application and use Silverlight. Silverlight runs applications in the browser, though, so you cannot make a "desktop" application using that.
Mono is working hard to make sure that Silverlight runs cross platform (as mentioned on one of the stack overflow podcasts). So that seems to be a good way to go.

Building C#/.NET Apps that Use Windows 7 TaskBar Features

The new Windows 7 taskbar features, like jump lists, previews, etc. are really cool, and I want to allow my C# applications to use them. I have two questions:
First of all, how can I use these functions (in general)? I found two articles by Microsoft about this, but I'm not really sure what to do. Could you provide links to a library, as well as some sample code?
Next, let's say that I figure out how to use these Taskbar functions. My question is, is there some built-in way of checking whether the OS is Windows 7, and thus enabling the taskbar functions? If I didn't have this logic in my app, would it have problems if it was run on a non-Win7 machine?
Thanks!
In the first article you link to there is a sample library that you can download that makes use of the new Windows 7 features.
This article shows how to check the version of Windows your application is running on.
As always, if you call an API that isn't in existence, then yes, your app will experience some turbulence. Remember, it's (almost) always better to check for a condition and act accordingly once (as in application startup) than to try something over and over in code and catch exceptions.
Windows API Code Pack for .NET Framework is your one stop shop for a ton of .NET API for Windows programming, including Taskbar. This library gives you a complete API set to work with Windows 7 Taskbar and then some. It also includes samples for WPF, and Winform.
Another good source for Windows 7 content is the Windows Team Blog

Compact Framework : any Finger Friendly GUI?

i m developing a little tool on my Pocket PC using WM6 SDK but i would like to implement a finger friendly user interface (iphone-like).
So i m looking for a free .NET framework that offers the possibility to easily integrate a finger friendly interface for Windows Mobile 6 Pro .
Any ideas ?
EDIT : Finger friendly means big icons, big buttons , scrollable screens with a simple touch of the thumb... Because the Winforms in Compact framework are made for the stylus, not fingers !!
I know of no such interface API.
I would code such an interface from scratch, overriding Paint and mouse events. If you need more fancy drawing tools that compact framework provides, you should look for pinvoke to access GDI+.
You should really check out Resco's MobileForms Toolkit 2009.
I bet their controls are exactly what you are looking for. Plus they have a whitepaper and videos to show off the controls.
I am not sure it is what you are looking for (I didn't have time to examine it yet myself, but I definately intend to); this UI Framework looks interesting:
http://code.msdn.microsoft.com/uiframework
Check out the Fluid windows mobile controls available at http://fluid.codeplex.com/
This might be what you are looking for, and its open source.
Any current readers on this thread should check out SlideUI (http://www.devslide.com/products/slideui). It's a current (and supported) product which offers touch friendly (iphone-like) scrolling and controls.
I'm not entirely sure what you're asking here... Windows Mobile 6.0 Pro is touch-screen enabled, so you should simply have to create your project targeting the Windows Mobile 6.0 Pro (note, however, that your application will not be compatible with Windows Mobile 6.0 Standard devices).
I know exactly what you are talking about. All the .NET Controls are designed for the stylus. When you make them bigger for the finger, there is no guarantee they will respond well. Add to that every hardware devices sensitivity is different and its even harder.
I recently built an application attempting to incorporate some touch like functionality. it was a pain having hand code all this stuff.
The problem with a 3rd party library, as opposed as coming in Windows MObile is then everyone is designing their own library and navigation techiques. Hopefully MS will wise up on this front.
http://sites.google.com/site/nebowiki/
If you are developing finger friendly apps, your target device needs a process to handle finger input as opposed to the stylus. HTC devices (Such as the Kaiser, Mogul, Touch Pro, etc.) use TouchFlo for this purpose. There are a few different versions of TouchFlo and I'm not sure if there is an SDK, but you need to incorporate it into whatever you program. xda-developers.com will have lots of info about it.
It IS amazing that with WM6.1 Pro, .NET CF 3.5 and VS2008 that all we have available are the basic stylus-sized controls that are are spartan in the extreme. i.e., coyote-ugly. I'm about ready to chew my hand off rather than use them in an app.
So where is the third-party collection of controls that all WM developers are flocking to, to provide touch-friendly apps?
Ugly is truly the correct word for most (mine included) mobile win apps.
I am developing for an older piece of hardware with a mono screen which makes it even worse.
Take a look here:
http://www.windowsfordevices.com/news/NS9328208835.html
and here:
http://msdn.microsoft.com/en-us/library/dd630622.aspx
This is not free, but it is affordable - some of the screen shots are pretty nice looking:
http://www.basic4ppc.com/?gclid=CIiO1di1nJoCFRAhDQodYX8-9A
Anyway...sorry if this was just googledragging - maybe it had something you had missed.
--Joe
Finger Freindlyness is a result of the touch screen technology (capacitive screens are less accurate, but require zero pressure; resistive screens require physical pressure and are harder to swipe, flick, etc.)
With Windows Mobile 6.5, they have introduced a system gestures library (and if you'd rather not have to P/Invoke it, there is a sample wrapper on MSDN Code Gallery). Theoretically, it would be possible to write to this new library, and maybe emulate the gestures on pre-WM6.5 devices, if required.

Categories

Resources