One of the projects I'm working on right now requires having a Silverlight object on a page grow to be larger and shrink to be smaller as its containing <div> area's size is changed using javascript. Below is the Silverlight embed code, and the relative javascript for using either jQuery or MooTools. All the javascript functions take action on a div section named 'resizableControlHost' which I added to wrap the normal 'silverlightControlHost' div section.

Basic HTML of Silverlight object embed (wrapped in a 'resizableControlHost' div):

<div id="resizableControlHost">
    <div id="silverlightControlHost">
        <object data="data:application/x-silverlight-2," 
                type="application/x-silverlight-2" 
                width="100%" height="100%">
        <!-- details removed -->
        </object>
    </div>
</div>

Resizing the 'resizableControlHost' div with jQuery:

function gotoSmallSize() {
    $("#resizableControlHost").animate({
        width: "200px",
        height: "100px",
    }, 500);
}

(click 'read more' to keep reading..)

If you're sharing common code between Windows Phone 7 and other platforms in either Silverlight or XNA, then you may run into a need to fork some code based on the platform. This is normally done with a preprocessor directive, which for Windows Phone 7 is WINDOWS_PHONE.

While sitting on the couch last weekend, I had the idea for putting up a Twitter panel on my site - you should see it off to the right. I figured since this is a Silverlight site, that it might be nice to actually have some Silverlight on it. I got the Twitter panel mostly done in 2-3 hours, and ended up using a few Silverlight features I haven't blogged about yet on the site - hence this blog post.

This post contains:

• Binaries for the Twitter panel so you can use it on your own site
• Passing in startup parameters from the object embed code
• A simple reusable Twitter assembly for Silverlight
• Source code for the Twitter panel
• Using Fluid UI to animate items added to the ListBox

(click 'read more' to keep reading..)

At the Atlanta Silverlight Firestarter a few months ago myself and Mason Brown did a talk 'Lighting Up the UI'. At the end of the talk I ranted a bit trying to encourage developers to think outside of the box when approaching UI's in Silverlight - to be open to creative ways in tackling new UI challenges. (You can find more on this talk in these posts on SilverlightAtlanta.net).

The example I went over in my example was a simple example of how to move an item from one ListBox to another. Most developers would look at this task the same way - they would remove the item being moved from the 'from' ListBox, and they would add the item to the 'to' ListBox. It would probably look something like this:

// get a handle on the item we are moving

ListBoxItem lbi = fromList.SelectedItem as ListBoxItem;

if (lbi == null)

    return;

fromList.Items.Remove(lbi); // remove it from the 'from' list

toList.Items.Add(lbi); // add it to the 'to' list

When you work with designers and usability engineers you'll often get challenged to do something which requires you to think outside the box. In this example the request is to get rid of the 'popping' between lists. The intent is to actually move the item, and show it moving from one list to the other - this is the sort of detail that can distinguish a standard app from a real user experience.

Here is a sample Silverlight application which shows off moving an item between lists both through the standard add/remove method, and our 'thinking outside the box' method we'll cover after the break:

(use the radio buttons to see the two ways of moving an item between ListBoxes)

(continue reading ...)

A simple, but hopefully decent, StatusBar example in WPF/XAML

Searching for information on new(er) technology can be pretty interesting. Sometimes you can find all the information you need, and other times you can't find anything. For whatever reason finding information on the StatusBar in WPF was one of those things where the articles written on the subject were slim pickings. Luckily it is really easy to reinvent the wheel in XAML if necessary once you know the basics.

It is pretty easy to create a StatusBar, it's just as you might imagine it would be in XAML:

<StatusBar>
  <TextBlock>Field 1</TextBlock>
  <Separator/>
  <TextBlock>Field 2</TextBlock>
</StatusBar>

The problem is that typically you need something a little more advanced in your StatusBar. You'll probably want regions which can expand/contract, a tooltip to read the truncated text, some columns which are fixed width, and you probably don't want your items to go off the edge of the screen if the window is too small or the text too large either. Keep in mind that the StatusBar container behaves like a DockPanel when your trying to make use of it.

Attached is a XAML file of the StatusBar example shown above. The basic premise is that the StatusBar contains a Grid which defines the areas on the StatusBar, and some of the fields are allowed to be as large as they need while others will be truncated if they are too long to fit.

You can make any TextBlock show the Ellipses(...) by using the TextTrimming and TextWrapping properties, or in a Style definition like this:

<Style TargetType="TextBlock" x:Key="StatusBarTextBlock">
  <Setter Property="TextWrapping" Value="NoWrap" />
  <Setter Property="TextTrimming" Value="CharacterEllipsis" />
</Style>  

.. just keep in mind that a TextBlock inside a StackPanel, or some other container allowed to grow horizontally indefinitely, will never show the ellipses because it will never actually be forcefully constrained - even if it is cut off and the full text isn't visible.

We also want to add the drag handle in the lower right corner of the Window, which can be done with the ResizeMode Window property like so:

<Window
  xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
  xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
  ResizeMode="CanResizeWithGrip">

Be sure to check out the XAML file attached and provide any suggestions you might have, or ask any questions, etc. Hopefully the keywords in this post will be good enough to help someone else down the line when trying to create a decent WPF StatusBar.

One of the more obvious issues with the initial post of the dialog XAML code last night was all the hardcoded colors, so this post will be a quick example of how to use defined colors and gradients instead so that when you want to change the colors you don't have to go looking through all the XAML to find where the colors are to modify.

Here is a snippet of the original XAML, specifically the blue gradient header across the top of the dialog and the white text on it:

    <!-- Top Panel (icon, description, help, etc.) -->

    <StackPanel Orientation="Horizontal" Width="500" DockPanel.Dock="Top">

      <StackPanel.Background>

        <LinearGradientBrush StartPoint="0,0" EndPoint="0,1">

          <GradientStop Color="Navy" Offset="0" />

          <GradientStop Color="MidnightBlue" Offset="1" />

        </LinearGradientBrush>    

      </StackPanel.Background> 

      ..

      <TextBlock Width="358" VerticalAlignment="Stretch" Padding="4,4,4,0" 

                 TextWrapping="Wrap" Foreground="White">

      ..

    </StackPanel>

 
The easiest thing to do right off the bat is to just take the LinearGradientBrush definition and move it up to a Resources section you create for the Page (or Window, etc.) - since we are working with a Page we will create a Page.Resources section right under the main Page definition:

  <Page.Resources>

    ..

    <!-- header panel styles -->

    <LinearGradientBrush x:Key="headerPanelFillBrush" StartPoint="0,0" EndPoint="0,1">

      <GradientStop Color="Navy" Offset="0" />

      <GradientStop Color="MidnightBlue" Offset="1" />

    </LinearGradientBrush>

    <SolidColorBrush x:Key="headerTextColor" Color="White" />

    ..

  </Page.Resources>

 
There are two brushes defined in that snippet - the 'headerPanelFillBrush' which is the blue gradient fill in the header, and the 'headerTextColor' which is the white color used for the text - these brushes will be referenced by the value we set for their 'x:Key' tag.

(click 'read more' to read the full article..)

So after two or three weeks of playing around with WPF/XAML I figured the best place to go next was to try and do some dialogs like I might do today in Windows Forms. I wrote these by hand using the Kaxaml tool mentioned on the recent Scott Hanselman podcast, and if you have that installed you should be able to make use of the .xaml files attached to this post pretty easily.

Keep in mind that this XAML is by hand (with Kaxaml's intellisense), not created via Blend or VS2008, and the XAML is probably atrocious to XAML experts - that's sort of the point. I'll be referring back to this project as I improve it - this post is just the initial post.

A simple dialog

(click 'read more' to read the full article..)