WPF

WPF Controls - how to avoid designer nastiness

Have you ever written any user controls or custom controls?
The difference between them is that with a custom control you have full scope to render it (plus you have to do it), whereas a user control is a container to amalgamate other controls.

With both of them though, you need to make sure that any calls made out of them are minimised.

Why?

Well because when they are created in WPF designers like Visual Studio 2008 or Expression Blend, they will be instantiated and therefore constructors will be called.
If you have calls out to databases etc, you will get a nasty looking exception thrown, or just the Visual Studio 2008 problem loading display:

How do you sort this problem?

By using the GetIsInDesignMode static method of DesignerProperties, like so
if (!DesignerProperties.GetIsInDesignMode(App.Current.MainWindow))
// do something you don’t want to appear in designer

WPF Controls

As I am architecting a new Line Of Business system for a customer, one of my thoughts is to recheck the situation with WPF controls.

The power and styleability of WP, with a few small exceptions, means that there isn’t quite the need for third party control libraries as there was in WinForms. In the days of WinForms it was a question of which of the main control libraries you picked, and how that was achieved with whatever ridiculous purchasing system was in place.

Now with WPF (and Silverlight soon), the focus has changed. There are a couple of holes in the WPF offering, like a paging grid, date time picker, numeric value editor. However, if you look at codeplex, most of the holes have been addressed by free controls. Also Xceed moved the goalposts for the component writing companies by giving away a top quality grid.
However, it’s not beyond some development teams to write their own controls as well - whereas that would have been a long, frustrating and expensive process in Winforms. I know because I have seen it
Another bad effect I see, is that some companies just won’t bother - and try to muddle through on their own , which does seem a mistake to me.

What does that mean for the major component vendors?
Well, in my opinion, it means they need to up their gameplan, and provide components on a different level. They can’t just provide decent grids and toolbars etc, that were missing from Visual Studio.
To be fair we have started to see the beginning of that, with carousels and ribbons

WPF Problems printing documents

Do you have problems printing documents in WPF?

My problem manifested itself when I tried to print a document from a FlowDocumentPageViewer (though the same is true from a FlowDocumentReader).
The problem I was getting was that if I had multiple pages, they would all be scaled and fitted onto the same size of printed page as on the screen.

How do you get around this?
Well the problem lies in the fact that the document is being shown on the screen which has a different size to the printed page.
Realising that, the solution itself is simple - change the height and width of the document before printing it, like:

Assuming docRdr is a FlowDocumentPageViewer and prtDlg is a PrintDialog:

FlowDocument doc = docRdr.Document;
doc.PageHeight  = prtDlg.PrintableAreaHeight;
doc.PageWidth   = prtDlg.PrintableAreaWidth;
prtDlg.PrintDocument(((IDocumentPaginatorSource)doc).DocumentPaginator, “Statement”);

Of course, you will need to remember to save the FlowDocument’s height and width, then re-apply after you have printed the document.

WPF Printing documents

I have blogged before on how you print a WPF element using the PrintVisual method in the PrintDialog class, which is very flexible as it will print any element derived from Systems.Windows.Media.Visual.
However, there is another weapon in the PrintDialog armoury, and that is the ability to print documents. Given the extensive document support in WPF, it comes as no surprise that you can easily print these documents.

To do that you need to get at the DocumentPaginator object - it’s purpose in life lies in managing content as pages which is just perfect for the job.
You get at it by using the IDocumentPaginatorSource interface, like this:

assuming docRdr is a FlowDocumentScrollViewer

PrintDialog prtDlg = new PrintDialog();
if(prtDlg.ShowDialog() == true)
{

prtDlg.PrintDocument(((IDocumentPaginatorSource)docRdr.Document).DocumentPaginator, “Statement”);

}

This will print the document for you just fine

WPF Printing - use the printing page

From a previous post of mine, you can see how to easily increase the size of a WPF element in order to print it.
That’s not much use though as you are still only hard coding the sizing.
What would be better is to use the height and width of the paper that has been selected.

Lo and behold, thats easy to do, using the PrintDialog class itself.
One further wrinkle is that you need to make sure that the actual element is resized, and you do that by telling it to resize itself.

Say you have an instance of PrintDialog called prtDlg:

Size pageSize = new Size(prtDlg.PrintableAreaWidth -30, prtDlg.PrintableAreaHeight - 30);
grd.Measure(pageSize);
grd.Arrange(new Rect(15, 15, pageSize.Width, pageSize.Height));

prtDlg.PrintVisual(grd, “My grid”);

Where grd is a Grid control containing a number of other elements

WPF Printing - why is it small

When you get to printing in WPF, you will find it so much easier than printing in previous Microsoft UI design (ie Winforms and MFC). See a previous post of mine to see how easy.

One thing that does occur though, is that when you print your element/canvas/grid/whatever, it will usually go on the printer very small. Why is that?
Actually, I think it is a good thing
What it means is that it’s printing exactly the same on the printer as on the screen, something we have been begging for, for ages [well since we’ve had GUI’s anyway].

So how can you make it bigger, well it’s pretty easy when you know how:

You simply make the element bigger by using a Transform before printing, like

grid.LayoutTransform = new ScaleTransform(6,6);
printDlg.PrintVisual(grid, “My vision”);

WPF Printing using PrintVisual

To do a simple print in WPF, you can do the following:

PrintDialog prtDlg = new PrintDialog();
if(prtDlg.ShowDialog() == true)
{
prtDlg.PrintVisual(element, “A simple drawing”);
}

This will throw up the XP or Vista print dialog, and then print the element specified, no problems at all.
Actually there are a couple of problems:

1. The element is always lined up in the top left of the printed page
2. If you haven’t specified any margin, the element might get cut off
3. There’s no pagination
4. It uses the same device independent system for printing as showing on the screen ,1:96, so an element 96 pixels wide will appear 1 inch wide on the printed paper

Printing with WPF

How does printing work with WPF?

Well, actually, if anyone out there has ever worked with printing in MFC, then it’s so advanced as to make you dizzy.
Even if you ever tried printing with Windows Forms, then printing in WPF is a bit of a revelation.

So how does it work?

Most of the printing stuff is in the System.Printing namespace, and a good starting place is the PrintDialog class.
By instantiating the PrintDialog class, you can display the standard xp or vista print dialog to allow the user to choose where to print something and how.

What else does it give you?

You can call two different methods to do printing:
PrintVisual - allows you print any class that derives from System.Windows.Media.Visual - which is a lot
PrintDocument - allows you to print any DocumentPaginator, e.g. FlowDocument or XpsDocument.

And it just works

Using Document Outline in VS2008 with WPF

I have recently rediscovered Document Outline in VS2008.

It was something that I relegated, in my head at least, to the world of web

However, I thought about a week ago - wouldn’t it be very handy if it showed me my complex xaml in a tree.
Lo and behold it did, andI could click on each node and go straight to the relevant DataTemplate

It was a nice and clean way to navigate the page, and dare I say it, easier than using Blend.
Obviously Blend has a lot of great features not in VS2008, but is a bit designer like for me sometimes

Data validation in WPF, my approach

Whether to use IDataErrorInfo or ValidationRule - that is the question, as I posed in a previous post.

So , you may be wondering what do I do in my WPF projects?
Or you may not

Well, I tend to use both!
I use IDataErrorInfo to provide validation in the business object itself, then derive extra classes from ValidationRule when I want validation across different business objects.

I have tried making the Validation classes always separate from the pure data business classes, but I found it to be counter productive and also counter intuitive.