Bill's Space

Windows Presentation Foundation (WPF) is great, but I have always felt that something was missing. WPF is the graphical subsystem for .NET Framework 3.0 and XAML is a declarative XML notation for describing user interface elements, data binding, eventing and even the structure of an application as a whole. The problem is that the Visual Studio tools for XAML and WPF have always seemed to be lacking. For starters, Visual Studio.NET 2005 does not provide assistance for wiring events and writing code-behind WPF controls. Developers are on their own for integrating UI elements and business logic.

Acropolis appears to be the amazing next step in the evolution of application development and is likely the reason that development tools for WPF appear to be lacking today. "Acropolis" is the code name for new toolkit for creating modular, business-focused Windows client applications. Acropolis builds on the .NET Framework and includes a run-time framework, design-time tools and out-of-the-box functionality.

Acropolis is specifically designed to help developers encapsulate business logic into "parts" and "services". Acropolis forms communicate with parts via "connection points". Acropolis provides a new, rich environment for creating loosely coupled applications.

Even cooler, Acropolis has the concept of Navigation Managers and Navigators which help bind user interface controls to parts and manage the state of navigation (such as visibility and enabled states). This concept should greatly simplify and standardize the development of rich user interfaces. Acropolis provides several out-of-the-box navigational patterns including: single part navigation, tabbed-pane navigation and split-pane structures.

Application development is about to get a whole lot cooler with Acropolis! WPF appears to be just the first step along the path to rich, loosely-coupled application development!

June 4, 2007 was my last day at SumTotal Systems.  I will deeply miss my “extended family”.

On June 18, I will begin a new journey as a Senior Consultant with Microsoft Enterprise Services!

Like many developers, I'm trying to learn the latest Microsoft technologies including WPF and Silverlight. A big part of learning Silverlight appears to learning what Silverlight is not. Silverlight is not WPF. (This was a surprisingly hard lesson!)

The tools that are currently available such as Orcas Beta 1 and Microsoft Expressions Blend are clearly first generation and are incomplete. As a result, I concluded that my best teacher would be experience and if I wanted to truly understand the technology in a deep way, I should learn to write it by hand first. And so, I cracked open Notepad.exe, a pile of books and MSDN. Soon I had "Hello World" mastered!

Getting beyond "Hello World" was harder. Quickly learned several important difference between WPF, Silverlight and HTML:

• Silverlight does not provide layout controls such as Stack, Grid, Table, etc. You are on your own when it comes to handling relative positions.
• Silverlight does not support relative sizing. For example, you cannot create a rectangle that is "50%" of the height and width of the canvas.
• Most of the common input controls such as CheckBox, ListBox, ComboBox, etc. are missing from the Silverlight arsenal. You will be writing them yourself.
• In the absence of common input controls, I'm incredibly concerned about Silverlights ability to ever support Accessibility. That's a shame.

I'm continuing to work my way through more complex examples. I'll continue to report new discoveries.

I'm a strong supporter of creating accessible software. Not only is it "the right thing to do", but I believe that designing for Section 508-compliance often results in user experiences that are more obvious, well-organized and portable to alternate experiences such as mobile devices.

While working with WPF and Silverlight, I've noticed a lack of commentary on accessibility. I've also noticed that accessibility-specific API's do not seem to be present on the WPF controls.

While I have seen articles indicating that WPF supports "Microsoft UI Automation" (which will be helpful for screen-readers), I do not see an obvious solution for keyboard-accessibility. I've also seen post such as this one on the Silverlight forum that suggests that accessibility in Silverlight will not be addressed until final release. I hope this is true.

Recent trends such as AJAX provide incredibly rich user experiences, but I fear that we are making a tragic mistake when we create content that is only available to "some people". AJAX is currently an accessibility concern because it often modifies areas of the screen in a non-linear fashion which only servers to confuse screen-readers. While producing creative experiences, I fear we may also sacrifice intuitive interaction, content indexing and portability to alternate devices.

I dream of the day when we learn to express user experience in terms of an abstract dialogue between a human and a machine, and we employ a "interaction stylesheet" that separates the intention and communication technique as brilliantly as "cascading stylesheets" separate structure from presentation today. Then, hopefully, we will truly realize access to information and behavior through multiple natural access methods including keyboard, mouse, remote control, mobile device and speech recognition.

I periodically checking on the W3C's XForms standard and I'm pleased to see that it's a great step in the right direction.

I've been recently writing code with Windows Communication Foundation (WCF) using raw Message contracts. The purpose of raw Message contracts is to allow the developer to be in complete control of the format of the message that is received and sent by a service. This is a good choice for the project that I'm working on because I am dealing with legacy code that is not strongly typed and I need the flexibility to process messages with structures that may vary between calls. (This is of course less than ideal, but it allows legacy code to function in WCF while we refactor the code.)

WCF provides several options for writing XML into your message. The Message.CreateMessage() method accepts Object (which will automatically be serialized using the Xml Serializer), XmlReader, XmlDictionaryReader or BodyWriter. The BodyWriter object provides an event that you can override to implement your own serialization.

In the project that I was creating, the data for my Message was already in XML, so I thought my most efficient solution would be to implement a BodyWriter that would simply write the raw XML into the stream. So I created the following class:

    public class SimpleMessageBody : BodyWriter
    {
        string xmlContent;

        public SimpleMessageBody(string content)
            : base(true)
        {
            this.xmlContent = content;
        }

        protected override void OnWriteBodyContents(XmlDictionaryWriter writer)
        {
            writer.WriteRaw(xmlContent);
        }
    }

I then used this class to be the input to the CreateMessage method as follows:

    message = Message.CreateMessage(MessageVersion.Default, 
                "http://tempuri.org/SomeMethod", new SimpleMessageBody(xml));

Much to my surprise, my XML content was automatically encoded in my method! However, if I opened an XmlReader on my XML content and passed the reader into the method, everything worked fine.

Eventually, I used the .NET Reflector utility to look deep inside the BodyWriter class. It turns out that the BodyWriter uses it's own special implementation of XmlWriter and when you look at this implementation, whenever you call the .WriteRaw() method, that method actually calls the .WriteText() method under the hood which ultimately encodes your raw XML!

It's possible that Microsoft wanted to prevent developers from writing raw XML into the message in order to prevent corruption, namespace conflicts or potential security violations. Unfortunately, this behavior does not appear to be clearly documented.

The only option appears to be to open an XmlReader and use the .WriteNode() method.

    protected override void OnWriteBodyContents(XmlDictionaryWriter writer)
    {
        using (StringReader stringReader = new StringReader(xmlContent))
        {
            using (XmlReader xmlReader = XmlTextReader.Create(stringReader))
            {
                writer.WriteNode(xmlReader, true);
            }
        }
    }

Microsoft has made a terrible change between Visual Studio 2003 and Visual Studio 2005. (I personally find it completely irresponsible.)

By default, Visual Studio 2005 projects have the “Check for arithmetic overflow/underflow” compilation switch turned off. In Visual Studio 2003, this switch defaulted to true.

What Does This Mean?

This means that if code attempts to multiply or add numbers that are very large (too large for the particular data type), the code will not throw an exception, but rather it will produce an unexpected result! This can lead to data corruption and potentially even infinite loops. (see “How We Discovered The Problem” below…)

Correcting the Problem

Every time you create a Visual Studio 2005 project:

• Right-click on the project and bring up Properties.
• Click on the Build tab.
• Click on the Advanced… button. (You may need to scroll down to find it.)
• Check the Check for arithmetic overflow/underflow checkbox.

Why Did Microsoft Do That?

Performance.

Checking for overflow requires a few extra programming cycles. Microsoft obviously traded safety for speed. (This is the equivalent of saying “I can make a car faster if I don’t include brakes”.)

How We Discovered The Problem

I had written a little function that operated on a byte. I wanted to write a Unit Test Case to ensure that the function worked as expected for all possible byte values, so I wrote the following code:

However, there is a serious bug in the code above. Once b == 255, this function will try to increment b one more time which should cause an overflow. Rather than overflowing, b actually became 0 and it became an infinite loop!

I was shocked that I did not get an overflow exception, so then I tried…

And I received 0!

So I tried…

And I received a large negative number.

And finally, I tried…

And I received -10!!!

At this point, I knew something was terribly wrong…

What If I Know That My Code Can’t Overflow?

In general, it’s better for us to be safe than sorry and always checked for overflow. HOWEVER, if you are 100% certain that you have a function that could never overflow, C# provides the unchecked { } block that allows you to mark a block of code to not require overflow checking.

I strongly advise against any developer actually using the unchecked statement unless you really, really, really know what you are doing!