In fact, VisualStates do not work directly inside of a ChildWindow. VisualStates are only applicable on the root element of a ControlTemplate or UserControl (as described here). I just spent the last 20 minutes learning about this limitation the hard way – by trying it, over and over. :)  It’s not a bug, it just isn’t supported.

If you want to use VisualStates within a ChildWindow, the simplest workaround for this problem is to wrap the content of the child window into a new UserControl and place that UserControl in the ChildWindow (as a child). You’ll need to do a little more work to expose the functionality of the UserControl to the containing ChildWindow (like OK/Cancel button handling for example), but it’s simple work. I added an event which indicates the child window should be closed:

public event EventHandler<CloseDialogEventArgs> CloseDialog;

public class CloseDialogEventArgs : EventArgs
{
    public bool? DialogResult { get; set; }

    private CloseDialogEventArgs()
    {

    }
    public CloseDialogEventArgs(bool? dialogResult)
    {
        DialogResult = dialogResult;
    }

    public static new CloseDialogEventArgs Empty = new CloseDialogEventArgs();
}

Then, it can be closed:

private void CancelButton_Click(object sender, RoutedEventArgs e)
{
    if (CloseDialog != null)
    {
        CloseDialog(this, new CloseDialogEventArgs(false));
    }
}

internal bool IsVerticalOrientation()
{
    StackPanel itemsHost = base.ItemsHost as StackPanel;
    if (itemsHost != null)
    {
        return (itemsHost.Orientation == Orientation.Vertical);
    }
    return true;
}

You might try deriving from StackPanel, but unfortunately, ArrangeOverride and MeasureOverride are both sealed methods on the StackPanel. So, you can’t. This behavior certainly limits what you can do with a ListBox layout.

What happens if you try something vertically oriented without a StackPanel host? The behavior is that the ListBox won’t properly scroll and activate the current ListBoxItem. Calling ScrollIntoView has no impact (as the math doesn’t work correctly when the IsVerticalOrientation isn’t properly handled).

Yet another feature of WPF that you’ll need to ignore for the time being. :)

I haven’t tried to solve the problem within the IDE as that’s a different problem. However, I have written the code to convert the output into something that you could stuff into a TextBox for example (which is what I’ve done in my Silverlight application – I’ve created a small debug window for RESTFul web service calls).

HttpWebRequest request = (HttpWebRequest)
    HttpWebRequest.Create(new Uri("http://localhost:12345/MyWebService.asmx"));

request.BeginGetResponse(delegate(IAsyncResult ar)
{
    HttpWebRequest req = (HttpWebRequest)ar.AsyncState;
    HttpWebResponse webResponse = req.EndGetResponse(ar) as HttpWebResponse;
    try
    {
        using (Stream stream = webResponse.GetResponseStream())
        {
            XmlReader xmlReader = XmlReader.Create(stream);
            try
            {
                XmlWriterSettings settings = new XmlWriterSettings();                            
                settings.Indent = true;
                settings.Encoding = System.Text.Encoding.Unicode;
                using (StringWriter strWriter = new StringWriter())
                {
                    XmlWriter xmlWriter = XmlWriter.Create(strWriter, settings);
                    try
                    {
                        // cool, this recursively writes all of the nodes!
                        xmlWriter.WriteNode(xmlReader, false);

                        // output it to the UI as a string 
                        Dispatcher.BeginInvoke(delegate()
                        {
                            txtRawResults.Text = strWriter.ToString();
                        });
                    }
                    finally
                    {
                        xmlWriter.Close();
                    }
                }
            }
            finally
            {
                xmlReader.Close();
            }

            stream.Close();
        }
    }
    finally
    {
        webResponse.Close();
    }
}, request);

Replace the Uri in the first line with a call to your web service that returns XML.

Steps:

1. The Response is requested asynchronously (as is the only option with Silverlight)
2. Within the anonymous method, the request is retrieved from the IAyncResult object instance (ar)
3. The async request is properly ended (EndGetResponse) and retreieved
4. The stream is fetched from the response and passed to a new XmlReader instance.
5. Create a new instance of the XmlWriterSettings object with indentation activated (Indent = True)
6. Create a new XmlWriter instance using a new instance of a string writer and the settings created in step #5
7. Recursively (thanks to the WriteNode method), write the entire document to the writer, formatted with indentations as requested!
8. Invoke back to the UI thread with the result of the formatted, recursive WriteNode call.
9. Clean up.

The Silverlight object framework is far more closed than the equivalent WPF framework. There are many more sealed class types and methods in Silverlight than in WPF. For example, Canvas in Silverlight is sealed. If you want to make a more interesting Canvas of some sort, you need to implement it from a base Panel. It’s not clear why classes such as Canvas are sealed in Silverlight.

Back to the TileBrush.

It’s not practical to try to extend the existing TileBrush in Silverlight to provide the tiling support offered by WPF so I took a very different approach.

As my tiling needs were straightforward, I created a new control, derived from Panel. The new control is called TilePanel. The TilePanel’s one and only task is, given an ImageBrush, and a few tile size values, tiles the brush to fill it’s container completely.

The use of the TilePanel is straightforward:

<local:TilePanel x:Name="pnlTile" TileWidth="32" TileHeight="16">
    <local:TilePanel.Image>
        <ImageBrush ImageSource="LED64x32-rect.png" />
    </local:TilePanel.Image>                   
</local:TilePanel>

Above, you’ll see the panel declaration, the width and height of the tile, and the brush that is used as the tiled image.

The TilePanel handles all of the details.

I created a small demo program to show off the tile support.

We have an exercise bicycle with an LED style display that inspired the simple demo program. It displays statistics and messages through the use of the bicycle. The demo allows you to change the text and the shape of the LED. Additionally, it shows how the tiles can be semi-transparent (the images used are 24-bit PNGs), allowing the content underneath to show through. In this case, it’s a large TextBlock which is animated within a clipped Canvas.

DispatcherTimer tmr = new DispatcherTimer();
tmr.Interval = TimeSpan.FromMilliseconds(250);
tmr.Tick += new EventHandler(UpdateCharacterPosition);
tmr.Start();

Any time the overall canvas changes size, the code adjusts the Clip property to a new rectangle (otherwise the text appears outside of the boundaries of the LED display).

private void TextHolderSizeChanged(object sender, 
SizeChangedEventArgs e)
{
    if (sender is Canvas)
    {
        Canvas c = sender as Canvas;
        RectangleGeometry rc = new RectangleGeometry();
        rc.Rect = new Rect(new Point(0, 0), e.NewSize);
        c.Clip = rc;
    }
}

To more efficiently update the TilePanel when multiple properties are being set at one time, I took a queued approach to the update:

protected void TileAdjustmentNeededAsync()
{
    // by doing this sync, we can queue up several request
    // but then really only handle the last one.
    _needsUpdate = true;
    // async call the adjust tiles
    this.Dispatcher.BeginInvoke(delegate
    {
        AdjustTiles();
    });
}

This way, a few properties can be set together, without the TilePanel needlessly recalculating and rebuilding the tiles.

The demo and the source code are located here (zip).

A few notes for those interested …

For maximum efficiency, if you use the TilePanel, try to make the Tiles sized so that fewer tiles are actually necessary to tile (create the tiles so that there are tiles within the brush you use). Instead of a tile that has only one image in it for example, consider building a tile which is really a 2 x 2 set of tiles.

One detail of the implementation that is important: you cannot reliably add new controls/UIElements to the Children collection of a Panel within the MeasureOverride or ArrangeOverride methods. Although the child UIElements are added without error, they typically will not render or display correctly. Building something like this TilePanel required a trick where the actual updates to the tiles always happen outside of the scope of an measure-arrange pass.

He thinks that the place to wire up an event is always in code rather than in markup (like XAML).

“What’s my opinion? I firmly believe the handlers belong in the code and not in the XAML.”

I’d suggest that’s not always right either (and maybe not the right question to ask). This technique doesn’t allow the designer to have freedom to decide how to build the interface freely. If you wire up to a “button” click, then the designer has to implement a certain UI feature as a button. Maybe that’s not what they wanted. The UI/code are wound together extremely tightly when using this pattern.

A command/message driven architecture that splits the actual implementation as much as possible is the best pattern for growth and true separation of roles. That being said, it’s not always practical to build a system like that.

I like the CONCEPT of WPF’s RoutedCommand system which is a way in WPF to handle this pattern, but I don’t care for the way that things are enabled and disabled via the CanExecute event handlers. The event handlers can be called hundreds of times a minute depending on your user interface.

The bad news is that Silverlight doesn’t lend itself easily to a message/command driven architecture (as the RoutedCommand system isn’t available in Silverlight 2.0). So what’s a developer to do? :)

I like the ‘toolability’ of doing inline (in XAML) wire-up of events. If the developer just provides a common set of end-points (events) to the UI designer, then they may have an opportunity to more freely control and adjust the user interface as needed without requiring code changes.

So in John’s example code, instead of

btnAddToCard.Click += new RoutedEventHandler(btnAddToCard_Click);

It might be better to provide a method called:

AddToCard(object sender, RoutedEventArgs e) {

}

That way, the designer can wire-up any way they want.

Or, I suppose one could build a rudimentary message/command system by using attached properties and a common event handler which handles all command driven user interface elements. (And now that I think about that more — I think that could end up being quite slick if done carefully).

IT shops, with trimmed budgets and staff, have little time to maintain workstations and troubleshoot interactions between various installed applications. Web applications, although they may be more challenging to write (regardless of adding complex RIA components), offer long term benefits for maintenance, updates, deployment and access control that are extremely difficult to emulate using any modern non-browser based alternative, from terminal servers to WPF XBAPs.

And no, I am not a firm believer that a user’s needs should be weighed less than the needs of the IT shop. By no means. But, I do believe that the experience and requirements of many LOB applications can be readily constructed within a web application. Moreover, many LOB applications should be web applications for portability and access reasons.

Not all LOB applications will benefit from the added functionality that would be provided by a Silverlight or Flash/Flex component. In fact, many users may needlessly suffer from a nearly pointless developer adventure into new technology explorations rather than being able to perform the same business task more efficiently with what might amount to a fully functional, yet boring LOB application.

Many applications would benefit however from added pizzazz. There’s plenty of power brewing within the likes of Silverlight and Flex. It needs to be measured and watched carefully, so that it doesn’t explode into the user’s face though.

I do take issue with suggesting that an XBAP is typically a better solution. WPF, even in its most reduced form, is heavy weight and complex. Being browser embedded, it also won’t behave like either a browser application or a fully installed application. So, neither experience is fully replicated for the end user. Eventually, it may be that every desktop has the latest and greatest version of the .NET runtime to allow for the latest XBAPs to work — but there in lies more of the problem — the desktop is making a key decision into whether an application may run, rather than the deploying machine. That stinks — and fewer companies and users want that.

Yes, a WPF application using XBAPs may, at some levels, be easier to write. It depends a lot on the developer and on the application needed. Many WPF applications are as hard to write as a web application (if not harder). It’s give and take. Some features are easier in one and vice versa. RIA code using Silverlight is easier to create than their WPF counterparts in some ways, only because the functionality is limited (and a few things simplified). But, throw in the web mix for interaction, and I agree that the complexities increase.

So much depends on the expectations and needs of the user. If you want a web experience with pages, etc., I wouldn’t consider an XBAP to be an ideal choice. If it’s mostly a single page where much of the interaction occurs, I could see XBAPs being a reasonable choice for Windows-only organizations. But, those must consider deployment, hardware requirements, .NET versioning, and more.

(Don’t get me wrong, I really like WPF — just installed as a traditional application. :) ).

Oh — and more importantly — don’t switch to either technology if there’s no business reason (sorry developers).

I’ve created a reasonably simple, yet multi-technology (and discipline) demonstration using Silverlight for the user interface and ASP.NET as the back-end. The demonstration uses:

• Silverlight 2.0
• Data binding
• Delayed downloading of images
• “Web services”
• ASP.NET
• LINQ
• Extension Methods
• Value Converters
• XAML
• IHttpAsyncHandler
• HttpWebRequest
• Google’s Weather Web Service (more of a weather XML end point)
• and more!!! :)

The Silverlight Weather control is a UserControl with a few bound TextBlocks, an Image, and a few rectangles, and the data input controls.

<TextBlock Margin="8,10,0,10" 
           Grid.ColumnSpan="2" 
           Grid.Row="5" 
           Text="{Binding CurrentWeather.Location}" 
           TextWrapping="Wrap" 
           x:Name="txtLocation1" 
           VerticalAlignment="Center" 
           Foreground="#FFF1F1F1" 
           FontSize="12" 
           FontWeight="Normal"/>

Standard Silverlight data binding … grabbing the CurrentWeather’s Location property (which in the example in the screen shot is Madison, WI). What I continue to find is that Silverlight does not allow data binding to the UserControl itself — which is a common trick I use in WPF all the time. I don’t know if it’s a bug or a feature though. So, instead of simple code like this:

public Page()
{
    InitializeComponent();
    this.Loaded += new RoutedEventHandler(Page_Loaded);
}

void Page_Loaded(object sender, RoutedEventArgs e)
{
    this.DataContext = this;
}

I’m forced to rely on a secondary layer for binding:

public Page()
{
    InitializeComponent();
    this.Loaded += newRoutedEventHandler(Page_Loaded);
    _binding = newPageDataBinding();
}

void Page_Loaded(objectsender, RoutedEventArgs e)
{
    LayoutRoot.DataContext = _binding;
}

This technique adds what isn’t a terribly useful layer for a project like this, but it shouldn’t be necessary. To work around the issue, I created a new class, called PageDataBinding which has the few properties I wanted to expose to the user interface:

public class PageDataBinding: INotifyPropertyChanged
{
    private WeatherCondition _currentWeather;

    public WeatherCondition CurrentWeather
    {
        get { return _currentWeather; }
        set
        {
            if (_currentWeather != value)
            {
                _currentWeather = value;
                RaisePropertyChanged("CurrentWeather");
            }
        }
    }

    #region INotifyPropertyChanged Members

    protected void RaisePropertyChanged(string name)
    {
        if (PropertyChanged != null)
        {
            PropertyChanged(this, new PropertyChangedEventArgs(name));
        }
    }
    public event PropertyChangedEventHandler PropertyChanged;

    #endregion
    
}

Above you should see the CurrentWeather property which I’ve used in the Silverlight UI. In addition to the typical button for activating the control, I’ve made the Enter key also trigger the weather fetching.

private void txtLocation_KeyDown(object sender, KeyEventArgs e)
{
    if (e.Key == Key.Enter)
    {
        FetchWeather();
        e.Handled = true;
    }
}

Above, after (starting the process of) fetching the weather, I’ve set the Handled property to true, which indicates no further processing of the key is needed.

I wrapped the basic request to Google into a class called Weather. It’s the job of the Weather class to package the request and submit it to my exposed web service. Google’s web servers do not have any of the cross domain permission files needed by Silverlight for it to directly access them; so, I created a proxy web service just for the purpose.

Using the HttpWebRequest object is quite simple:

public void Download()
{
    try
    {
        HttpWebRequest request = WebRequest.Create(
            new Uri(Application.Current.Host.Source,
                string.Format(
                "../GetWeather.ashx?location={0}", _location))) as HttpWebRequest;
        request.Method = "GET";
        this._responseResult = 
            request.BeginGetResponse(new AsyncCallback(RequestCallback), request);
    }
    catch (Exception ex)
    {
        Debug.WriteLine(ex);
    }
}

I’ve just made the request to my web server and passed the location parameter directly. If it’s gibberish, Google just returns an error, so I don’t bother with any special processing (and in the end, it’s just a demonstration).

When the response is received, the RequestCallback method is called:

private void RequestCallback(IAsyncResult result)
{
    HttpWebRequest request = result.AsyncState as HttpWebRequest;

    HttpWebResponse response = (HttpWebResponse) request.EndGetResponse(result);

    Stream s = response.GetResponseStream();

    StreamReader reader = new StreamReader(s);
    string webResult = reader.ReadToEnd();
    Debug.WriteLine(webResult);
    reader.Close();
    response.Close();

    if (WeatherDataDownloaded != null)
    {
        WeatherDataDownloaded(this, new WeatherDataDownloadedEventArgs(webResult));
    }
}

Not necessarily production ready code, but it works for this demo. The result is returned, and gathered into a string. Once complete, the Weather class raises an event with the result to the host user interface.

I won’t replicate all the code here, but once the user interface event code is called, it begins to parse the XML data:

void WeatherDataDownloaded(object sender, WeatherDataDownloadedEventArgs e)
{
    XElement xd = XElement.Parse( e.Data, LoadOptions.None);

    var conditions = from current_condition in xd.Descendants("current_conditions")
                     select new WeatherCondition()
                     {
                         Condition = current_condition.GetChildElementAttributeValue("condition", "data"),
                         TemperatureF = current_condition.GetChildElementAttributeValue("temp_f", "data"),
                         TemperatureC = current_condition.GetChildElementAttributeValue("temp_c", "data"),
                         Humidity = current_condition.GetChildElementAttributeValue("humidity", "data"),
                         IconPath = current_condition.GetChildElementAttributeValue("icon", "data"),
                         Wind = current_condition.GetChildElementAttributeValue("wind_condition", "data")
                     };

As you can see, I use LINQ and an extension method I frequently use to obtain a named attribute from an element. The extension method, GetChildElementAttributeValue doesn’t do much really:

public static string GetChildElementAttributeValue(
    this XElement element, XName elementName, XName attributeName)
{
    XElement subElement = element.Element(elementName);
    if (subElement != null)
    {
        XAttribute attr = subElement.Attribute(attributeName);
        if (attr != null)
        {
            return attr.Value;
        }
    }

    return null;
}

The primary function (of this function!) is to protect against null elements when trying to read an attribute value.

The attribute values are stored in a WeatherCondition object. Once the object has been created, and a little more work is done, the code must notify the UI’s bound objects.

WAIT! If the notification happens now (on the currently executing thread), the Silverlight runtime will absolutely throw an exception, just like WPF would. The current executing thread is not the user interface thread, so I’ve used the Dispatcher to execute the update on the user interface thread:

Dispatcher.BeginInvoke(delegate()
{
    _binding.CurrentWeather = conditions.First<WeatherCondition>();
});

The remainder of the Silverlight code is mostly basic plumbing and user interface manipulation. There should be more error trapping than there is … but, I’m leaving that for another day (or for you!).

Rather than introducing a true web service into the project, I instead created an IHttpAsyncHandler in ASP.NET. This way, the handler could efficiently make requests of the Google Weather API and return them, without blocking further requests. In an ideal world, I’d add caching and more error handling ….

Here’s nearly the entire handler — as I think it’s useful to demonstrate a live, working usage of an ASP.NET async HttpHandler. If you’re not familiar with IHttpAsyncHandler, and you’re writing HttpHandlers, … get familiar with it if you care about scalability/performance.

public IAsyncResult BeginProcessRequest(HttpContext context,
 AsyncCallback cb, object extraData)
{
    _context = context;
    HttpWebRequest request = WebRequest.Create(
        new Uri(
            string.Format(
            http://www.google.com/ig/api?weather={0}, 
          context.Request.QueryString["location"]))
            ) as HttpWebRequest;

    _completedCallback = cb;        
    return request.BeginGetResponse(
       new AsyncCallback(GetResponseCallback), request); 
}

private void GetResponseCallback(IAsyncResult result)
{
    Debug.WriteLine("GetResponseCallback");
    HttpWebRequest request = result.AsyncState as HttpWebRequest;
    HttpWebResponse response = request.EndGetResponse(result) as HttpWebResponse;
    Stream s = response.GetResponseStream();
    StreamReader reader = new StreamReader(s);

    string responseOutput = reader.ReadToEnd();
    reader.Close();
    response.Close();

    _context.Response.ContentType = "text/xml";
    _context.Response.Write(responseOutput);

    _completedCallback.Invoke(result);
}

public void EndProcessRequest(IAsyncResult result)
{
    _context.Response.End();
    
}

I’ve also created an IValueConverter to take the path to an image and convert it to a bitmap image.

BitmapImage bi = new BitmapImage();
bi.UriSource = new Uri("/Images/" + path, UriKind.Relative);  

The images are stored on the web server rather than being embedded directly into the XAP file. Note that for this to work, the images must be stored in the ClientBin/Images folder, … not the /Images folder of the web server (as the path is relative to the location of the Silverlight download, not to the web application).

One issue that I ran into that had me puzzled for a while. AG_E_NETWORK_ERROR. This error occurred when trying to directly download the images Google uses for weather icons. That error had me baffled, until I realized that Silverlight cannot download images from other domains, unless they have the cross domain XML files properly configured for remote access. Google, sadly, does not have them, so I created my own images using Expression Design. The original file can be found in the download if you’re interested (as a series of layers).

Download source code for entire project (including graphics) here.

Enjoy!

See a picture below: :)

I ran into one odd issue when using Silverlight 2.0 Beta 2….

void Page_Loaded(object sender, RoutedEventArgs e)
{
    // if you don't invoke this asynchronously, you can't add at load time
    // (seems to be a silverlight 2.0 issue)
    Dispatcher.BeginInvoke(delegate()
    {
        consoleCanvas.AnimateNewChild(
                string.Format("Welcome!\nThe time right now is {0}.", 
                DateTime.Now.ToLocalTime()));
        consoleCanvas.AnimateNewChild("\n\nThanks for stopping by WiredPrairie.us. "
            + "This code may be used for only for good, not evil.");
    });
}

The code above for example — if the ConsoleCanvas control (the simple base control for the console output-like functionality) performs any UpdateLayout calls within the context of the Load event, the entire Silverlight control fails to load, silently. The only work-around I could discover was to delay what I wanted to occur by using the asynchronous invoke method on the Dispatcher object.

The easiest way to force a UIElement to measure itself is to use a little trick:

_holder.Width = this.ActualWidth;
child.Width = this.ActualWidth;
_holder.Children.Add(child);
_holder.UpdateLayout();

child.Width = child.DesiredSize.Width;
child.Height = child.DesiredSize.Height;

The console control maintains a visible (yet opacity is set to 0.0) StackPanel. Each time a new line of output is added via the AnimateNewChild method, it’s placed in the StackPanel. The StackPanel (_holder) is resized to fit the current width of the entire ConsoleCavnas control. Next, the UpdateLayout method of the StackPanel is called — which forces an immediate measure of all of the children (and thus forces any children of the TextPanel to potentially re-layout). The width and height are grabbed and permanently stored as the new size for the child.

Instead of using Storyboards and various animations, I found it more convenient to simply use a DispatchTimer and do the animations manually.

List<FrameworkElement> remove = new List<FrameworkElement>();

for(int childIndex = 0; childIndex < this.Children.Count; childIndex++)
{
    FrameworkElement child = this.Children[childIndex] as FrameworkElement;

    if (!child.Equals(_holder))
    {                        
        child.Arrange(new Rect(0, Canvas.GetTop(child), 0, 0));
        double top = Canvas.GetTop(child);
        top -= 2.0;
        Canvas.SetTop(child, top);                       
        if (top + child.Height < 0.0)
        {
            remove.Add(child);
        }
    }    
}
// remove them all 
remove.ForEach(fe => this.Children.Remove(fe as UIElement));                

If an element is no longer visible on the screen, it is removed using a Lambda expression and the ForEach method on the List object instance named remove (after the repositioning loop has completed).

Download source, etc. here.