In a previous post, I showed a good way to do alternating row styles in a ListBox.

I recently discovered that .NET 3.5 SP1 adds extended framework support for doing this.

If you are fortunate enough to be developing with the bleeding edge (3.5 SP1), see this MSDN page for an example and documentation of the new framework support.

Please use the comments form for topical feedback on specific articles.

In WPF, there are often many ways of accomplishing the same end result. I recommend always looking for the most "correct" solution, and that in my opinion is the one that most naturally fits in with the framework hooks already provided, as well as being the most generic and reusable solution possible.

The Problem

Simple. How do I implement alternating row styles in a ListBox?

Building Blocks

The following, provided in the framework, will be useful:

• The ItemContainerStyleSelector property of the ItemsControl class
• The StyleSelector base class
• The static ItemsControlFromItemContainer method of the ItemsControl class
• The IndexOf method of the ItemCollection class

You may have glossed over the following code in my previous post:

        PrintTicket ticket = new PrintTicket();

        ticket.PageOrientation = PageOrientation.Portrait;

        ticket.CopyCount = copies;

        PrintCapabilities capabilities = queue.GetPrintCapabilities(ticket);

        ...

        writer.WriteAsync(documentPaginator, ticket);

And I couldn't blame you for it. On the surface it doesn't appear all that significant or interesting.

But the reason behind creating and using a custom PrintTicket goes beyond setting the number of copies for the print job.

FlowDocument objects are a great way to present information with flexible layout options. WPF provides several viewer controls to easily visualize FlowDocument instances in a UI. One of the big benefits of the viewers is that they format and paginate everything automatically, not only for the display area but also for printing. This makes it a snap to generate dynamic documents (e.g., receipts in an ordering system), display them on the screen, and print them with correct layout and pagination.

The Problem

The problem is that the viewer controls (FlowDocumentReader, FlowDocumentPageViewer and FlowDocumentScrollViewer) each offer a single public entry point for printing, such as Print, that offers only the default Windows printing behavior. This means the old ugly Windows Print Dialog pops up. You cannot automate printing in any way using this approach.