In the final part of this series, we’ll discuss mixing page orientations and performance. A video demo of the solution can be found here: [http://www.youtube.com/watch?v=cfvJgwNbc9I&hd=1]
 
The invoice document that we’ve created so far contains a number of “Page-Masters” that are “portrait”. If you need to perform a “landscape” insert then you simply need to switch the “DesignHeight” and the “DesignWidth” dimensions of the Xaml-Page-Master.
 
<UserControl x:Class="WpfInvoice.template001.TimeDetails"
             xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
             xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
             xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006"
             xmlns:d="http://schemas.microsoft.com/expression/blend/2008"
             mc:Ignorable="d"
             d:DesignHeight="1120" d:DesignWidth="800">
    <Canvas>
 
…
 
    </Canvas>
</UserControl>
 
 
Moreover, you need to rotate all controls by 90 degrees anti-clockwise:
 
<TextBlock HorizontalAlignment="Left" TextWrapping="Wrap" Text="Time Details" VerticalAlignment="Top" Height="30" Width="158" FontSize="24" FontWeight="Bold" Canvas.Left="17" Canvas.Top="945" RenderTransformOrigin="0.5,0.5">
    <TextBlock.RenderTransform>
        <TransformGroup>
            <ScaleTransform/>
            <SkewTransform/>
            <RotateTransform Angle="-90"/>
            <TranslateTransform/>
        </TransformGroup>
    </TextBlock.RenderTransform>
</TextBlock>
 
 
If you are populating a dynamically-expanding grid on the landscape page then you need to ensure that the rotation takes place from the top-left-hand-corner of the grid. This has the effect of anchoring the control. Failure to do this will cause unpredictable “data-expansion” problems.
 
Example of dynamically expanding grid (landscape)
 
<Grid x:Name="GridGuide" Visibility="Visible" Canvas.Left="164" Canvas.Top="1037" Width="955" ShowGridLines="True" RenderTransformOrigin="0,0">
    <Grid.RenderTransform>
        <TransformGroup>
            <ScaleTransform/>
            <SkewTransform/>
            <RotateTransform Angle="-90"/>
            <TranslateTransform/>
        </TransformGroup>
    </Grid.RenderTransform>
    <Grid.RowDefinitions>
        <!--<RowDefinition Height="25"></RowDefinition>
        <RowDefinition Height="25"></RowDefinition>-->
    </Grid.RowDefinitions>
    <Grid.ColumnDefinitions>
        <ColumnDefinition Width="72*"></ColumnDefinition>
        <ColumnDefinition Width="10*"/>
        <ColumnDefinition Width="150*"/>
        <ColumnDefinition Width="10*"/>
        <ColumnDefinition Width="470*"/>
        <ColumnDefinition Width="10*"/>
        <ColumnDefinition Width="70*"/>
        <ColumnDefinition Width="10*"/>
        <ColumnDefinition Width="70*"/>
        <ColumnDefinition Width="10*"/>
        <ColumnDefinition Width="72*"/>
    </Grid.ColumnDefinitions>
</Grid>
 
 
The video demo illustrates the performance of the solution. As you can see it’s very fast… (in fact faster than SSRS in a production environment). A typical data-merge and render of over a hundred pages will only take a few seconds. The only limiting factor for this is the speed at which data can be supplied to the client.
 
The reason it’s so fast is because you are off-loading the processing requirements onto a local machine (as opposed to the SSRS shared server resource).
 
Remember, the performance should not sway your decision to move away from SSRS.The Wpf route is only favoured when you can’t do what you need to do in SSRS.
 
 
REGARDS