Geeks With Blogs
Imran Shaik Silverlight Quintessential Rambling

Let me first start by saying that I was very much excited about creating a Silverlight multitouch application ever since I heard the announcement that Silverlight supports it, I couldn’t wait to try porting some of our Surface applications to Silverlight.

From a pure feature perspective Silverlight Multitouch doesn’t really provide much since Silverlight Multitouch can only work on  Windows 7 running on a Multitouch capable hardware (HP Touchsmart TX2 in my case) and when you create a web application you can’t expect only 0.001% (probably I am overrating figures here) users to be able to use the application. But all things aside since Microsoft took the trouble of providing Multitouch support in Silverlight 3, I went ahead with the trouble of checking it out.

Although the question of including a non usable feature in Silverlight 3 ahead of other important features (eg., Mic/Web cam support) was raised, the answer I was told was that Surface team was ready with it so they went ahead and included it anyways. I was pretty much satisfied with that answer with anticipation of what I could possibly do with Silverlight Multitouch capabilities.

When the initial excitement died, the first thing that surprised me with that statement was that why would Microsoft take up a decision of including a Multitouch library and unnecessarily increase the plug-in size just for the sake of “Silverlight supports Multitouch” tag line while Silverlight is still struggling with ubiquity against Flash, given the possibilities of what Multitouch in general provides I was pretty sure that there would definitely a huge chuck of framework that might have to be thrown in to at least get it working and it would also mean that all base classes right from UIElement have to be rewritten or wired to support touch and Multitouch, or just like Surface include an interface that will enable touch on existing Silverlight controls but either ways a moderately big chuck of framework have to be thrown at Silverlight.

Alas, I finally got my Multitouch laptop and I was finally able to take a look at Silverlight Multitouch, I was so excited to port our Surface DJ application to Silverlight. My excitement was very short lived, there was only a single static class “System.Windows.Input.Touch” which have nothing except for a single static event “FrameReported”. I cursed, didn’t see that coming, should have, but didn’t.

Nonetheless, I thought maybe I could think of some situation and be able to create some simple application with that might be possible with that one static event and not requiring the whole touch framework. I tried and tried and tried, thought I was doing something wrong when I checked and rechecked couldn’t find anything sinister there, I was pretty sure that my Visual Studio or Silverlight installation might have some problems, there was something fundamentally wrong going on. Don’t want give up… yet…

I went down from a sophisticated application to a very simple one -  two regions (or rectangles) a black and a white, splitting  the whole screen vertically and showing the number of contacts registered on each side, sounds simple right? Wrong! I was getting equal number of contacts on both sides and each one is representing any touch irrespective of where it was touched.

Huh? But why? Where is the sender? Where or how do I know weather the black rectangle got the touch or the white? Without it I obviously can’t know which side was touched. (Don’t get excited I know we can still calculate, just read on),. The EventHandler for the event FrameReported obviously have an parameter “sender”, but since I am not associating my Touch event to any object (rectangle in this case) and since the event itself is a static event, it is always null. I have to look else where… but where?

The EventArgs for the event FrameReported, exposes TouchFrameEventArgs class, which actually includes a property Timestamp (atleast something to hold on to), along with three other methods

  1. GetPrimaryTouchPoint
  2. GetTouchPoints
  3. SuspendMousePromotionUntilTouchUp.

All these methods are self explanatory, although the GetPrimaryTouchPoint and GetTouchPoints takes in a parameter UIElement and returns point/(s) relative to that UIElement, they still doesn’t provide the object or the sender which have actually registered the  touch event.

Ah! Probably since I am attaching the Touch.FrameReported event on whole UserControl I might be getting the touch relative to the whole UserControl. For now, I went ahead and calculated the position of the touch points to get actual touch points on black and white rectangles. Satisfied that I atleast got that working, I wanted to take it to the next level, show random ellipses which only appear for a moment on each region (black/white), and two users can compete with each other, the user who touch on maximum number of these ellipses in a minute wins the game.

Based on the problems I faced previously and my newly formed assumptions I hatched a plan, instead of checking touch on the whole application I will create these ellipses as UserControls and enable touch inside those UserControls, these UserControl on registering a touch will raise an event which will be caught by the main UserControl and do the score and remove that Ellipse visually (so that user can’t touch it again), this way I can identify which UserControl was touched and who should get the points. Promising right?

I went ahead and implemented that, there was only one problem when I touch one ellipse all ellipses were getting removed and both black and white was registering the score! Sigh! What now? On debugging I figure out that if there are two ellipses on the screen the ellipse UserControl is raising the event twice! But why? I am not even touching the second Ellipse, just the one!

No, I am ready to give up… yet.

Maybe… Maybe… since I am also registering Touch on the main screen to determine if black/white region got touch (Which actually took me a while to figure out). Maybe that is the culprit, and since TouchFrameEventArgs inherit from EventArgs and not RoutedEventArgs I can’t suppress the event from bubbling, so the only option with me is to remove it. I went ahead and removed it, made sure that there are no more FrameReported events anywhere in the whole application except for the ellipse user control. Still the same result. But why is it raising the event twice when I touching it only once? Maybe the answer is lurking somewhere in that.

I keep telling myself… don’t give up yet… keep trying, maybe you are doing something wrong…

It came to me suddenly, as a revelation in the form of an accidental touch where there are no ellipses -  breakpoint reached… ellipse raised the event that it got touch. Yeah, you read that right.

Touch in Silverlight is irrelevant of the object that might or might not  be where it got touched, doesn’t matter if its HitTestVisibility is on or off, furthermore it doesn’t even matter if it is visually visible or not, if an “touch enabled” object is included in the visual tree irrespective of any other factor, it will raise that event. And Touch event is only relative to one entity – the whole screen. Even if you want to write your own touch framework, it won’t be possible since Silverlight natively doesn’t support complex HitTesting it would not be feasible to ever determine which objects got the touch, and without that the whole point of Multitouch is irrelevant, unless of course if you are enabling multitouch to your whole application (eg.,

Now coming to the point, Why is it included in Silverlight? Only reasons unknown to mankind. All things said, do I still have an option of not giving up on Silverlight Multitouch? One reason not to give up? I hope and pray that I am doing something wrong, that there is something wrong with my Multitouch driver installation or something else.

But for now my encounter with Silverlight Multitouch is going to be just that – brief.

Posted on Monday, September 7, 2009 10:13 AM Silverlight | Back to top

Comments on this post: A brief encounter with Silverlight Multitouch.

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © Imran Shaik | Powered by: