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:for(byte b=0; b <= 255; b++)
{
    myFunction(b);
}

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…byte b = byte.MaxValue;
b++;
Console.WriteLine(b);

And I received 0!

So I tried…int i = int.MaxValue;
i++;
Console.WriteLine(i);

And I received a large negative number.

And finally, I tried…int i = int.MaxValue;
i *= 10;
Console.WriteLine(i);

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!

I work a lot with XML and XML will obviously play an important role in future development. Over the last couple of months, I've been observing some incredibly strange behaviors with namespaces. I was certain that I must be observing a bug in Microsoft's XML Parsers, so today I decided I was going to finally figure out what was happening.

Take the following example:

<html xmlns="http://www.w3.org/1999/xhtml"> 
    …     
    <a href="http:someurl" mce_href="http:someurl" >     
    … 
</html> 

Question #1: What is that namespace for the "a" element?

Answer #1: It's "http://www.w3.org/1999/xhtml".

Question #2: What is the namespace for the "href" attribute?

Answer #2: Did you say "http://www.w3.org/1999/xhtml"? Wrong! It's actually null!

What? That didn't make any sense, so then I tried using an explicit prefix on the elements…

<h:html xmlns:h="http://www.w3.org/1999/xhtml"> 
     … 
     <h:a href="http:someurl" mce_href="http:someurl" > 
     … 
</h:html> 

When you use an explicit prefix on elements then the namespace for both "a" and "href" becomes "http://www.w3.org/1999/xhtml".

This certainly seemed like a bug, so I went straight to the source. . . the W3C.

http://www.w3.org/TR/2006/REC-xml-names-20060816/#scoping

Amazingly enough, it's not a bug! If you use a default namespace, then elements with no prefix belong to the default namespace; however, attributes have a null namespace. If you use a namespace prefix on elements, then attributes with no prefix have the same namespace as their containing element!

I have absolutely no idea why the W3C chose this behavior, but it's incredibly important if you are trying to write XPath expressions or are using the Microsoft XML classes.

Understanding this behavior should save you from a lot of frustration!

Happy Coding!

The website for Interfaith Voices of Youth (http://www.interfaithvoicesofyouth.org/) is now up and running!

Okay, this is just too funny. . . http://www.rathergood.com/

“Those who would give up essential liberty for temporary safety deserve neither liberty nor safety.”

– Benjamin Franklin

Woohoo! wkfry.net and mickpark.net are finally hosted on a real external server! Many thanks to dotservant.com!

I’m very happy to announce that there are two major updates to my site.

First, I have finally updated Micky’s website with his latest masterpieces. (www.mickpark.net)

I have also updated my personal photo albums with two new sections that cover that last six months.

My best friends sent me the coolest Christmas Gift that I’ve ever received. Since I’ve moved to Seattle, I’ve often complained that all of my “comfort foods” are in Rochester. The west coast does not have the Italian influence that the east coast has, so there is no such thing as an excellent pizza, sub or fish fry in Seattle.

For Christmas, Tim and Misty went to my favorite pizza joint in Rochester (Chester Cab pizza) and had them make two, deep dish pizzas which they froze and shipped overnight packed in dry ice.

This is by far the most thoughtful presents I’ve ever received.

One of the pizza’s has “already been enjoyed” and I’m saving the other for a special occasion.

Thank you, guys! You rock!

Last Wednesday, we had an enormous wind storm. When we woke up, the power was off. When I drove to the end of the driveway on the way to work, I remembered that I had left the garbage can outside and the wind had probably blown it away.

I stopped the car and started to look for the garbage can. After a few moments, I saw that it was over next to a tree branch on the road. Upon further inspection, it wasn’t just a limb, but rather one of our large pine trees that had fallen, broken the fence and was laying across the road.

As we continued to inspect, we found not just one tree had fallen, but rather three enormous pine trees.

Fortunately, none of the trees hit the house, but we were four days without electricity. We made extensive use of the wood fireplace and it will soon be time to buy our first chain saw. . .

So, Monday was my first full day in our new home. During the day, I was visited by a family of four raccoons and two deer in the front yard. We are really out in the sticks! :-) It’s pitch dark at night and there is not a sound. We couldn’t be happier. . .

Woohoo! It’s official. . . we own a house!

Well, I think I have converted to an iTunes user. Although I don’t have my High-Efficiency format (which really is a shame), Low-Complexity at the highest setting is stunning, too. And yes, iTunes works nicely with the multimedia keys on my keyboard, just like Windows Media Player.

I finally have a very nice media player that does MP4 after years of waiting. The last nail in the coffin will be whether the new SoundBlaster Wireless (or some other wireless music vendor) will support MP4 audio. If they do, I’m gone for good. . .

Good-bye Windows Media Player. . .

Dang it. iTunes still doesn’t support MP4 High-efficiency mode yet.MP4 comes in two forms: Low-complexity and High-efficiency. Low-complexity is particularly useful for portable devices because it can be decoded with much less process power; however, high-efficiency has incredible sound quality.

I have literally spent months encoding all of my CD’s into HE format because it sounds incredible, but iTunes still does not support it. I’m sure this is because of marketing. . . they want to make sure their music can work equally well on a portable device.The MP4 standard is SOOOO good. It’s really incredible. I really want to see it succeed because the detail is beyond words. But unfortunately, the support is so poor that I feel like I really went down a losing path. It’s only been within the last two months that I found a decent DirectShow codec that will allow me to finally play my music through Windows Media Player.

I’m trying really hard to fight for the superior alternative, but it’s just not there yet. . .

So it’s really happening! On Monday, we sign for the house. It suddenly became real yesterday when a nice young lady called and said “Can you come in on Monday to sign?” When I looked at my watch, there was a brief sense of panic.

So, I finally have a blogger. . . let’s see how this goes. . .