学步园

1.  Application Model

1.1 Is WPF resolution independent?

This is an occasionally confusing aspect of WPF. Thank Charles Petzold for his concise and definitive answer:

The Windows user is ultimately responsible for setting an assumed resolution of the video display. This is done in the Display Properties applet. Commonly this assumed resolution is 96 or 120 DPI but it could be set higher. This has been the case for several past versions of Windows and it remains unchanged in Vista.

The assumed resolution is independent of the actual resolution of the monitor. The user can try to set the assumed resolution equal to the actual resolution, but there is little reason for it. But again, nothing has changed with Vista.

WPF programming involves device-independent units of 1/96th inch. If the assumed resolution of the video display is 96 DPI, then WPF DIUs correspond directly with pixels. If the assumed resolution of the video display is 120 DPI, then WPF DIUs are equal to 1-1/3 pixels.

Functionally, there is no real change. For decades, Windows programmers have either been obtaining the assumed resolution of the video display or using mapping modes based on this assumed resolution. The whole process is somewhat more convenient in WPF than in previous Windows APIs, but it's functionally the same.

The WPF DIU is only something the programmer sees. It does not affect users at all. Users are not required to make any adjustments to accommodate the WPF DIU.

Related threads:
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=3057227&SiteID=1
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2566603&SiteID=1
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1857144&SiteID=1
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2804844&SiteID=1

Currently integration and interoperation between XBAP and ASP.NET is quite limited. Fortunately you can use HTML iframe element to host XBAP application, and use either cookies or query strings to communicate between ASP.NET and XBAP. Furthermore, if you really need a richer integration or interoperation features, you could try Silverlight (a subset of WPF) which is designed and optimized for web scenario.

Related threads:
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2870386&SiteID=1

1.5 How to use Windows Forms control (e.g. Crystal Report Viewer) in a WPF application?

Related threads:
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2909472&SiteID=1

1.6 Is it possible to subclass from XAML generated class in WPF?

Related threads:
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2829770&SiteID=1
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2710858&SiteID=1

The current version of WPF doesn't support subclassing from XAML generated class if the subclass also uses XAML. In order to let the base class inheritable by XAML generated subclass, you need to write the base class completely in code.

We can use WindowsFormsHost element to host a Windows Forms control in WPF. Here is an example which shows how to host a CrystalReportViewer

2. Base Services (Threading, Keyboard/Mouse handling & Dependency Properties)

2.1 Where is Application.DoEvents in WPF?

Unlike Windows Forms, WPF doesn't directly provide an Application.DoEvents() equivalent to allow developers to start nesting message pumping. When writing Windows application, you'd better try to avoid using nested message pumping, because nested message pumping could cause some subtle problems such as code reentrancy, and what's more, WPF will disable nested message pumping when doing layout, visual tree traversal among other things.

But there would be some rare situations in which nested message pumping could be useful, such as unit testing, the following helper class could provide the Application.DoEvents like feature in WPF:

/// <summary>
/// Encapsulates a WPF dispatcher with added functionalities.
/// </summary>
public class DispatcherHelper
{
    private static DispatcherOperationCallback exitFrameCallback = new
         DispatcherOperationCallback(ExitFrame);

    /// <summary>
    /// Processes all UI messages currently in the message queue.
    /// </summary>
    public static void DoEvents()
    {
        // Create new nested message pump.
        DispatcherFrame nestedFrame = new DispatcherFrame();

        // Dispatch a callback to the current message queue, when getting called,
        // this callback will end the nested message loop.
        // note that the priority of this callback should be lower than that of UI event messages.
        DispatcherOperation exitOperation = Dispatcher.CurrentDispatcher.BeginInvoke(
            DispatcherPriority.Background, exitFrameCallback, nestedFrame);

        // pump the nested message loop, the nested message loop will immediately
        // process the messages left inside the message queue.
        Dispatcher.PushFrame(nestedFrame);

        // If the "exitFrame" callback is not finished, abort it.
        if (exitOperation.Status != DispatcherOperationStatus.Completed)
        {
            exitOperation.Abort();
        }
    }

    private static Object ExitFrame(Object state)
    {
        DispatcherFrame frame = state as DispatcherFrame;

        // Exit the nested message loop.
        frame.Continue = false;
        return null;
    }
}

Related threads:
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2034805&SiteID=1
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=602081&SiteID=1

2.2 How to access WPF controls from another thread?

Like many UI frameworks such as Windows Forms, WPF also imposes a single threading model, which means that you can only access a specified DispatcherObject derivative from the thread which creates it. In Windows Forms, each Control will implement ISynchronizeInvoke interface, this interface exposes a set of methods such as Invoke and BeginInvoke to impose a common thread synchronization contract which we could use to access a control from another thread. In WPF, we also have such type of thing, but those operations are wrapped up in a class called Dispatcher, Dispatcher is WPF way of enabling this type of thread synchronization model.

The following is an example of how to modify the TextBox.Text property when the caller is in a different thread:

// Resets textbox text from another thread
textBox.Dispatcher.Invoke(DispatcherPriority.Background, new Action(() =>
{
    textBox.Text = "New text";
}));

Related threads:
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=3024118&SiteID=1

3. Controls

3.1 How to expand all nodes (TreeViewItems) of TreeView control?

Unlike Windows Forms, the current version of WPF doesn't provide a straightforward way to expand all nodes of TreeView control with a single line of code. Generally speaking, there are two ways to implement this feature. The first method is to leverage WPF's Styling capability as the following XAMLPad ready example shows:

TreeView>
</Page>

Sometimes, you need a programmatic way of doing this, and then you could use the following C# helper method to expand all nodes:

public static class TreeViewHelper
{
    public static void ExpandAll(TreeView treeView)
    {
        ExpandSubContainers(treeView);
    }

    private static void ExpandSubContainers(ItemsControl parentContainer)
    {
        foreach (Object item in parentContainer.Items)
        {
            TreeViewItem currentContainer = parentContainer.ItemContainerGenerator.ContainerFromItem(item) as TreeViewItem;
            if (currentContainer != null && currentContainer.Items.Count > 0)
            {
                // Expand the current item.
                currentContainer.IsExpanded = true;
                if (currentContainer.ItemContainerGenerator.Status != GeneratorStatus.ContainersGenerated)
                {
                    // If the sub containers of current item is not ready, we need to wait until
                    // they are generated.
                    currentContainer.ItemContainerGenerator.StatusChanged += delegate
                    {
                        ExpandSubContainers(currentContainer);
                    };
                }
                else
                {
                    // If the sub containers of current item is ready, we can directly go to the next
                    // iteration to expand them.
                    ExpandSubContainers(currentContainer);
                }
            }
        }
    }
}

The key to this technique shown above is to make sure that the container for the current TreeViewItem has been generated, so you can safely expand it to show all its sub items. That's why you need to make a recursive call when the status of current TreeViewItem's ItemContainerGenerator is GeneratorStatus.ContainersGenerated.