For those that don't know, I have been a Winforms dev since about 2001. Before that time I was just as interested in graphics and usability as I was in coding itself. While in college I was pursuing a computer science degree in class, but my free time wasn't spent coding in Java or reading books on operating systems, it was spent in Photoshop and Flash 4. In fact, I was doing more advanced stuff in Flash Actionscript at the time than I was doing in my college CS courses. I had hoped that when it came time to graduate from college I would be able to get aboard the Flash bandwagon - creating super cool UI's for the web - unfortunately the dot com bubble burst, and my coding abilities were what kept me gainfully employed.

Up until creating an entry for the Server Quest Silverlight contest I had never touched Silverlight. I was definitely aware of it, but I was a Winforms guy, not a web guy - so I was elbows deep learning WPF and Prism and doing WPF LOB work for my current employer - I had no plans of touching Silverlight. Now that I've finished my first major Silverlight app, Matchingo, I find myself questioning which direction I want to go next - do I go back to WPF, or do I keep on trucking in Silverlight?

(click 'Read More' below to keep 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.

I just spent a few minutes trying to figure out an odd error I was having in trying to add Kevin's WPF Bag-o-Tricks to my MemoryGame project. Apparently if you make use of such a 3rd party control (or anything with a different app domain) in one XAML file and then attempt to put that XAML page into another XAML page (whose project does not contain a reference to said 3rd party library) you will get this lovely error:

Since I last posted I have still been relatively hard at work learning a variety of things. One thing which I have noticed recently is that once you get a basic sense of WPF/XAML/etc. you'll probably have been exposed to so many other things relative to WPF to learn that you'll spend less and less time UI/XAML coding and more and more time researching new technologies that seem to go hand-in-hand with WPF.

One of the interesting paradigms with the Windows Forms -> WPF switch is that if you are going to take the time to move to WPF you are likely to do a good bit of architecting, or be able to include other new features in .Net 3.5, etc. Maybe now is the time to also bring in other new things you've wanted in your codebase - maybe better unit testing, LINQ, new design patterns, etc. Maybe in trying to learn WPF and build your new product you've realized you need a good architecture to go along with the new app as well?

I would suggest that if you are going to be doing some WPF work you probably should be familiar with design patterns and frameworks which work well with it. A good example would be CompositeWPF - also known as "The Composite Application Guidance for WPF" or Prism. What you'll find on codeplex and this corresponding MSDN page is a WPF friendly design pattern framework from Microsoft complete with a bunch of source code examples, documentation, etc.

A few of the technologies incorporated into CompositeWPF are a dependency injection(DI) (or Inversion of Control (IoC)) implementation named Unity (somewhat like a more advanced form of a service-locator design pattern), implementations of the Model View ViewModel (MVVM) design pattern (a widely accepted WPF friendly replacement for MVC or MVP), and several other notable technologies you will probably want to check out as well.

What's great about learning these frameworks is that just like trying to learn XAML/WPF there are lots of good resources out there. Searching for any of the keywords above can give you plenty to read and look into, but before you get started I would highly suggest this recent hour long episode on .Net Rocks on exactly these topics: dnrTV Show #124 - Brian Noyes on Prism. Also, once you get into the QuickStarts which come with the framework be sure to use this corresponding page to know what is going on in the examples.

Well, I'm off to keep looking through the example projects that come with CompositeWPF, and maybe try out my own implementation. Until next time!

A month or so ago before I got too far into my WPF research I wanted to figure out how the performance of WPF compared to - say a 486DX 33mhz from 12-13 years ago. That was about the time I really got into coding, and about the time one of my buddies showed me how to code a fire algorithm in inline assembler in Borland Pascal. So, I looked online for some way to render bitmaps in memory and display them in WPF - and that led to the WPF Fire application whose source is attached (.exe can be found in the bin folder of the attachment as well).

The fire algorithm is pretty simple. You have a color palette of 0 through 255 representing black to white with reds and oranges in between (or you can do black to white with gray shades to make it look like smoke). The way it works is that the bottom row of pixels has their colors randomly assigned to either 0 or 255. All the other pixels on the screen have their colors based on the average of the colors of the pixels to the left, right, and directly beneath - we also decrease the value of this average a bit too so that the fire gradually fades out from bottom to top. Since we are averaging the values around each pixel and the pixel below it makes it appear as though the flames are moving from the bottom to the top. What is neat about this simple algorithm is that you could use it in conjunction with other things. For example, you could remove the randomly assigned pixels at the bottom which fuel the fire, and instead have white balls bouncing around the screen for example which would appear to have fire trails based on the averaging pixel passes.

Now that .Net 3.5 SP1 is out there is a DirectX panel you can use in WPF - I'm sure that would be 10x better for coding something like this - but since I have no real intention of revisiting this playtime app I figured I would share it and see if anyone out there might hax0r it into something cool (please let me know if you do).

A few weeks ago I mocked up a UI and tried to create it. I got it pretty far but put it aside after one night and thought I had lost my work. Tonight I found it and was pretty surprised to see how much I already wanted to refactor after just a couple of weeks of continued reading.

I am publishing the UI as a click-once app so it can be run online, and I am posting the source too for anyone that might want to hax0r at it. The app shows off a simple reflection as well as a series of custom textboxes which grow when they gain focus. There are tons of things I would like to improve in this UI mockup, but I would rather get it posted now and move on to something more challenging.

Click the screenshot below to play with the app online

Update: Source code now attached.