Charlie Robbins

XamQuery: Reconciling the "theory" and "reality" of WPF vs. Silverlight

Mon, 22 Feb 2010 16:07:00 GMT

Disclaimer: This technology does not actually exist yet, I am looking for feedback about this idea and anyone interested in working on it.

I’m sure a lot of you have seen this image. It highlights some of the pain of working with Silverlight coming from a WPF background.

It occurred to me over the weekend that this is really a statement about the consistency of the implementation of XAML DOM APIs. With that in mind the next logical conclusion was that there is a very important parallel in the Javascript world, i.e. the consistency of the implementation of the Javascript and HTML DOM APIs. Thankfully since about 2005, much of this pain has been encapsulated into jQuery.

So what about XAML? What can we do about it? This is where XamQuery would come in. Here’s a highlight of the core features I see and where I have needed them:

A XAML DOM selector engine similar to Sizzle. Given that XAML doesn’t have complex selector syntax like CSS this would essentially be a highly optimized tree walker for the VisualTree that would wrap the disjoint APIs in WPF / Silverlight for getting visual parents and children.
A set of fluent APIs for creating XAML DOM objects (Panels, Controls, etc) that would wrap some annoying inconsistencies when travelling between Silverlight and WPF as well as making it easier to do things in code that are painfully verbose in pure XAML (I think states of the VSM is a great example of this).
A simple plug-in system for System.Interactivity Attached Behaviors to attach into. This would mirror the jQuery plugin system where each selector statement actually returns the jQuery object which you can then call plugins on.

Feel free to contact me directly about this idea. I’m looking to get some like minded developers together to work on this. I think that this could be the thing that takes WPF and Silverlight development to the next level.

Posted by Charlie Robbins

Parsing JSON into dynamic objects using MGrammar and C# 4.0

Thu, 11 Feb 2010 20:11:00 GMT

I gave a talk last week at the New Jersey .NET User Meetup Group on designing textual DSLs using MGrammar. You can download the slides here: Textual DSLs with MGrammar. The code portion of the project was focused around developing a JSON parser into dynamic objects in C# 4.0. JSON has become an increasingly popular data format over the last several years for it’s flexibility and simplicity. The entire JSON specification can be summarized in just five words: objects, arrays, values, numbers, and strings. Each of these diagrams has a clear representation in MGrammar shown below:

Objects


syntax Object 
  = ObjectStart first:KeyValuePair rest:ObjectPart* ObjectEnd => Object { Pairs { first, valuesof(rest) } };

syntax ObjectPart
  = Comma pair:KeyValuePair => pair;

syntax KeyValuePair
  = key:String Colin value:Value => Pair { Key { key }, Value { value } };

Arrays


syntax Array
  = ArrayStart first:Value rest:ArrayPart* ArrayEnd => Array [ first, valuesof(rest) ];

syntax ArrayPart
  = Comma value:Value => value;

Values


syntax Value 
  = string:String => string
  | number:Number => Number { number }
  | object:Object => object
  | array:Array => array
  | primitive:Primitive => Primitive { primitive };

Numbers


token Number = Minus? Digit+ ('.' Digit+)? Exponent?;
token Exponent = ("e" | "E") Sign? Digit+;
token Digit = "0" .. "9";
token Sign = Plus | Minus;
token Minus = "-";
token Plus = "+";

Strings


syntax String = '"' text:(text:StringText | empty) '"' => String { valuesof(text) } ;
token StringText = !('\u0022')+;

Inside the Parser

Much of the actual parsing is done using simple LINQ expressions. First through, you have to install Visual Studio 2010 and the SQL Modeling November 2009 CTP (formerly “Oslo”) and created a new “Oslo Library.” This is important because it sets up all the M and MGrammar dependencies for you.

After you’ve created your Oslo Library, you must add your *.mg file and set the build action to “MCompile.” This will use the M tools to compile the *.mg file into a *.mx image. After that’s completed we can create our parser at runtime:


MImage grammar = new MImage(@"jsonm.mx");
grammarParser = grammar.ParserFactories["jsonm.jsonm"].Create();
grammarParser.GraphBuilder = new NodeGraphBuilder();

Now that we have our parser we can use that to parse the raw text into MGraph:


var inputText = new StringTextStream(sourceText);
var errorReporter = new ParserErrorReporter();
Node rootNode = (Node)grammarParser.Parse(inputText, errorReporter);
JsonmObject obj = ParseObject(rootNode);
return obj;

The rest of the process uses a series of LINQ expressions using some extension methods (included with the project). Here’s an example of how objects are parsed:

private static JsonmObject ParseObject(Node objectNode) { JsonmObject jsonmObject = new JsonmObject();

List<Tuple<string, object>> keyValuePairs = objectNode
    .Edges.FindNodeWithBrand("Pairs")
    .Edges.FindNodesWithBrand("Pair")
    .Select(node => ParseKeyValuePair(node))
    .ToList();

foreach (Tuple<string, object> pair in keyValuePairs)
{
    jsonmObject.TrySetMember(
        new DynamicDictionaryMemberBinder(pair.Item1, false),
        pair.Item2);
}

return jsonmObject;

}

You can see in the above example that in addition to parsing the MGraph, it sets members on our dynamic dictionary. This is how we can parse some sample JSON like this:


{
    "Object" : 
    {
        "String" : "StringValue",
        "Number" : -1.4e1,
        "null"   : null,
        "true"   : true,
        "false"  : false
    },
    "Array"  : [ "StringValue", 42, false, true, null ],
    "String" : "StringValue",
    "Empty"  : "",
    "Number" : -1.4e1,
    "null"   : null,
    "true"   : true,
    "false"  : false
}

Into a dynamic object using our parser like so:


dynamic result = JsonmParser.Parse(new Uri(Environment.CurrentDirectory + @"\sample.json"));
Console.Out.WriteLine(result.Object,String); // ==> "StringValue"

As always this code is on GitHub. I look forward to see more parsers in MGrammar in the future, send any MGrammar hacks my way in email or comments!

Posted by Charlie Robbins

Capturing Raw Images from the Microsoft Surface

Fri, 22 Jan 2010 05:25:00 GMT

Surface Multi-touch

As I mentioned in a previous post the Microsoft Surface implements multi-touch using infrared computer vision as opposed to a capacitive approach. This is interesting for a couple of reasons. First it allows the Surface to recognize a very large number of touches. Second, it allows ambitious developers to tap directly into this infrared image data to perform more complex operations (like shape recognition). Getting at this information however is not entirely straight forward though. To simply things I created an attached behavior.

Attached Behaviors

Attached behaviors are something that I’ve blogged about before. They are a very convenient way to add user interface behavior to controls without having to implement a proper subclass. This behavior also implements a custom attached event, which allows you to easily handle and process images captured from the Surface.

Using the Behavior

Using the behavior is simple; you just have to include the library in your solution, add the xmlns and set a couple of attached properties and an event handler:


<s:SurfaceWindow
  behaviors:SurfaceWindowRawImageCapture.IsEnabled="True"
  behaviors:SurfaceWindowRawImageCapture.RawImageCaptured="YourEventHandler">
  (...)
</s:SurfaceWindow>

Optional Parameters

This behavior is designed to be flexible. There are several parameters that allow you to take advantage of this flexibility.

UseExplicitCapture=(true | false)

Setting this property to true will disable the attached event from being raised. It is false by default. Use it if you want to capture images programmatically which is explained below.

SaveTo=”C:\path\to\captured\images

Often it may be necessary to save the images that you capture to a specific location. If you set this property all images captured by the behavior will be saved to the specified directory.

Capturing Images Programmatically

The one drawback to the way that the Surface SDK allows developers to capture raw images is that the ContactDown event must be handled on the instance of the SurfaceWindow itself. What that means is that your attached event handler has to also be on the SurfaceWindow itself. The solution to this limitation is to call the behavior programmatically from your own code:


SurfaceWindowRawImageCapture.CaptureRawImageAsync(
    Application.Current.MainWindow as SurfaceWindow,
    new Rect(100, 100, 100, 100),
    result =>
    {
        // Code to execute when the result has been captured
    });

The Rect that is passed to the method defines an area to crop the entire Surface image. This is useful if you are only interested in a small sub-area of the total Surface. The callback that is passed to the method will be executed after the image has been captured.

Let me know if you run into any issues with the behavior by emailing me: charlie [you know] robbins [obviously] gmail [you know] com. As always, all of this code is available under the MIT license on GitHub.

Posted by Charlie Robbins

Fudging the non-client area of Custom Chrome Windows using WPF and Win32

Fri, 15 Jan 2010 23:12:00 GMT

Now that I’m back from staycation I’ve been looking around at some miscellany that needs to be done at the Lab. One of those items used my open-source (MIT ftw)Custom Chrome Window library. In the process of using it I came across a little bug that’s discussed on the WPF Window Chrome site here.

Basically, even though the “Caption bar” (aka “Title bar,” aka “Window bar,” aka “Non-client Window area”) was hidden, the Window.Top and Window.Left calculations take it into account. After a colleague of mine did some serious Google-foo on Win32 we found this solution which has been added to the library on GitHub. The solution is outlined below, starting with including some Win32 API calls:


public static class SafeNativeMethods
{
    [DllImport("user32.dll")]
    public static extern int GetWindowLong(IntPtr hwnd, int index);

    [DllImport("user32.dll")]
    public static extern int SetWindowLong(IntPtr hwnd, int index, int newStyle);

    [DllImport("user32.dll")]
    public static extern bool SetWindowPos(IntPtr hwnd, IntPtr hwndInsertAfter, int x, int y, int width, int height, uint flags);

    [DllImport("user32.dll")]
    public static extern IntPtr SendMessage(IntPtr hwnd, uint msg, IntPtr wParam, IntPtr lParam);

    internal const int WS_CHILD = 0x40000000;
    internal const int WS_VISIBLE = 0x10000000;
    internal const int LBS_NOTIFY = 0x00000001;
    internal const int HOST_ID = 0x00000002;
    internal const int LISTBOX_ID = 0x00000001;
    internal const int WS_VSCROLL = 0x00200000;
    internal const int WS_BORDER = 0x00800000;


    public const int GWL_EXSTYLE = -20;
    public const int GWL_STYLE = -16;
    public const int WS_EX_DLGMODALFRAME = 0x0001;
    public const int SWP_NOSIZE = 0x0001;
    public const int SWP_NOMOVE = 0x0002;
    public const int SWP_NOZORDER = 0x0004;
    public const int SWP_FRAMECHANGED = 0x0020;
    public const uint WM_SETICON = 0x0080;
    public const int WS_DLGFRAME = 0x00400000;

    public const int WS_SYSMENU = 0x80000;
    public const int WS_MINIMIZEBOX = 0x20000;
    public const int WS_MAXIMIZEBOX = 0x10000;
}

After which we need to call into these methods in the CustomChromeWindow class:


protected override void OnSourceInitialized(EventArgs e)
{
    base.OnSourceInitialized(e);

    // Get this window's handle
    IntPtr hwnd = new WindowInteropHelper(this).Handle;

    // Change the extended window style to not show a window icon
    int extendedStyle = SafeNativeMethods.GetWindowLong(hwnd, SafeNativeMethods.GWL_EXSTYLE);
    int style = SafeNativeMethods.GetWindowLong(hwnd, SafeNativeMethods.GWL_STYLE);

    SafeNativeMethods.SetWindowLong(
        hwnd, 
        SafeNativeMethods.GWL_STYLE,
        style & ~SafeNativeMethods.WS_SYSMENU & ~SafeNativeMethods.WS_MINIMIZEBOX & ~SafeNativeMethods.WS_MAXIMIZEBOX & SafeNativeMethods.WS_DLGFRAME);

    // Update the window's non-client area to reflect the changes
    SafeNativeMethods.SetWindowPos(
        hwnd, 
        IntPtr.Zero, 
        0, 0, 0, 0,
        SafeNativeMethods.SWP_NOMOVE | SafeNativeMethods.SWP_NOSIZE | SafeNativeMethods.SWP_NOZORDER | SafeNativeMethods.SWP_FRAMECHANGED);
}

Hopefully you’ll never have to wallow in the pain of custom window chrome, but if you do take a look at the library on GitHub.

Posted by Charlie Robbins

Pseudo-Inherited Attributes in MGrammar (@November 2009 CTP)

Sat, 26 Dec 2009 00:11:00 GMT

The M language and in particular MGrammar have caught my attention recently after completing Programming Languages and Translators this past semester at Columba. I didn’t take compilers as a part of my undergraduate studies at McGill and after completing Professor Aho’s course I am really intrigued by the possibilities offered by DSLs and DSVs.

After getting setup with .NET 4, the SQL Modelling November 2009 CTP, and Intellipad my first inclination was to see how I could implement some classic ideas in language theory with MGrammar. One such idea is “inherited attributes.” An inherited attribute is a value that is captured or calculated at a parent node in an abstract syntax tree and then passed down to child nodes for any calculations or translations that they may need to perform. A classic example of this would be the “with” keyword that is available in Javascript:


with (myObj) {
  x += 3;
  y += 3;
}

This would be equivalent to:


myObj.x += 3;
myObj.y += 3;

Posted by Charlie Robbins

Adding ContactMultiTap to the Microsoft Surface

Fri, 25 Dec 2009 06:32:00 GMT

The Surface SDK comes in two flavors; WPF and XNA. All of the input events on the WPF Surface SDK are implemented as Attached Events, which are essentially just a clever use of standard Routed Events in WPF. I won’t delve into the all details here about what Attached Events are, but they were a primary focus for an implementation of ContactMultiTap on the Surface.

For those of you not familiar with the Surface, it’s convenient to think of it as a gigantic iPhone (although it’s been around in secret long before the iPhone) that can also recognize object tags (like 2D barcodes). This is because instead of using a capacitive multi-touch approach like the iPhone it implements a multi-camera computer vision system and interprets inputs from that. In this post, I discuss my implementation as well as the benefits of time-based multi-tap input on this “big a** table.”

Posted by Charlie Robbins

Microsoft unshackles the Surface SDK

Wed, 18 Nov 2009 19:09:00 GMT

Recently, I have been more involved with development on the Microsoft Surface as part of my work with the Computer Graphics and User Interfaces Lab. We also have a couple of Surfaces here at Lab49. The Surface is a very interesting device to me because of it’s potential not necessarily as a consumer device but in marketplace and enterprise scenarios. Furthermore, it’s SDK is implemented in WPF using very clever tricks like attached events.

One thing that frustrated me about the Surface though, was how closed off its development community had been. If Microsoft really wants this thing to take off (a topic that has been the subject of heated debate), then why not just let anyone who wants to download the tools and SDK to test it out? Well it seems that Microsoft has come to their senses and put all the Surface materials (technical resources, documentation, and downloads) up for public consumption. If you’re a UI enthusiast or just a WPF developer I highly suggest checking it out:

Download Surface SDK 1.0 (SP1)
Surface Documentation on MSDN
New Surface Forums

Happy Coding!

Posted by Charlie Robbins

Interesting Findings between .NET 4 Beta1 and Beta2

Thu, 22 Oct 2009 15:21:00 GMT

Patrick Smacchia has an interesting post on interesting findings in the diff between .NET 4.0 Beta1 and Beta2. I've been a little behind the times on updates, but this article brought me up to speed with some API changes quickly. Some interesting changes to System.Windows.Input to reflect the native Multi-Touch support for Window7. I wonder how the Surface SDK will change with the transition from Vista to Win7.

Posted by Charlie Robbins