Jason Prickett's Blog : WPF

CollapsibleSection - Hiding Paragraphs until the user wants to see them in a FlowDocument

Jason Prickett — Thu, 23 Apr 2009 16:39:10 GMT

As I mentioned back in January, I created a collapsible section for use in a flow document. In my case, I was removing a treeView and replacing it with indented paragraphs in a flow document (see the previous post as to why). Some of the data that was now shown to the user all the time was rather useless in most cases. So, I had some suggestions to put back the tree. Well, I just didn’t want to lose my beautiful new FlowDocument, so I started experimenting. I noticed that a Section could contain paragraphs or any other type of Block. Naturally, I wondered how hard it would be to create a section that only showed its contained children when some property was changed. So, I wrote the code and this is how it turned out…

internal class CollapsibleSection : Section
{
    public CollapsibleSection()
    {
        CollapsibleBlocks = new List<Block>();
        Header = new Paragraph();

        m_expandCollapseToggleButton = new ToggleButton();
        m_expandCollapseToggleButton.Click += new RoutedEventHandler(ExpandCollapseToggleButton_Click);
        m_inlineUIContainer = new InlineUIContainer(m_expandCollapseToggleButton);
        m_inlineUIContainer.BaselineAlignment = BaselineAlignment.Center;
        m_inlineUIContainer.Cursor = Cursors.Arrow;

Header.Inlines.Add(m_inlineUIContainer);
}

    private void ExpandCollapseToggleButton_Click(object sender, RoutedEventArgs e)
    {
        Invalidate();
    }

public Paragraph Header { get; private set; }
public List<Block> CollapsibleBlocks { get; private set; }

    public bool IsCollapsed
    {
        get
        {
            return !(m_expandCollapseToggleButton.IsChecked ?? false);
        }
        set
        {
            m_expandCollapseToggleButton.IsChecked = !value;
        }
    }

    public void Invalidate()
    {
        Blocks.Clear();

        if (CollapsibleBlocks.Count == 0)
        {
            m_expandCollapseToggleButton.IsChecked = null;
        }

Blocks.Add(Header);

        if (!IsCollapsed)
        {
            Blocks.AddRange(CollapsibleBlocks);
        }
    }

private ToggleButton m_expandCollapseToggleButton;
private InlineUIContainer m_inlineUIContainer;
}

As you can see, it was fairly easy to create this class. Not very much code at all. The class has a Header property that is the one paragraph that you see all the time and contains the toggle button. It also has a CollapsibleBlocks property that you can add any type of Block to. When the user clicks the button the IsCollapsed property is toggled and the Header and CollapsibleBlocks are used to modify the built-in Blocks property of the section.

I left out all the work I did after the fact to make the toggle button look like a triangle and rotate when clicked, but you should be able to figure that stuff out the same way I did, by looking at the way a TreeView works.

And here’s how I used the class:

   CollapsibleSection section = new CollapsibleSection();
   section.Margin = new Thickness(parentIndent, StandardPadding, 0, 0);
   section.IsCollapsed = false;

. . .

section.Header.Inlines.Add(header);

. . .

section.CollapsibleBlocks.Add(new Paragraph(new Run(“test paragraph”));

section.Invalidate();

I don’t like having to invalidate the section after I have added everything, but I didn’t want to spend a lot of time trying to figure out a clever way around it.

I hope this gives you an example of just how extensible FlowDocuments are and why I like them so much!!!

WPF Documents - Indenting Paragraphs

Jason Prickett — Wed, 07 Jan 2009 18:01:00 GMT

As I promised, this is a post about what I learned while creating a flow document that had indented paragraphs. The hierarchy was dynamically built based on the data.

The first thing I noticed is that indenting a paragraph is very easy, just set the left margin of the paragraph and the entire paragraph will be indented. If you want just the first line of the paragraph indented, simply set the TextIndent property. In either case, the value is a double that represents WPF device indendependent units. If you want the first line to be outdenting, or you simply want a hanging indent. You have to set the left margin to the hanging indent value and then set the TextIndent to the negative of that value.

Another way to indent a paragraph is to add it to a section that has the left margin set. Sections don't have a TextIndent property, but a section can contain another section (unlike paragraphs). So, If you nested 3 sections that all had an indent of 20.0, the result would be that the inner most section would be indented 60.0 units from the left edge of the window. I didn't use this approach because I didn't have to. It was simple enough for me to simply indent each paragraph accordingly.

So, that's a lot of talking without any code or pictures. Here is some XAML to demonstrate indenting:

<FlowDocumentScrollViewer>
     <FlowDocument>
         <Section>
          <Paragraph>
       This paragraph is not indented in any way and should wrap normally. This paragraph is not indented in any way and should wrap normally. This paragraph is not indented in any way and should wrap normally.
          </Paragraph>
      </Section>
         <Section>
          <Paragraph TextIndent="50">
       The first line of this paragraph is indented by 50 units, but the rest of the lines will not indent at all. The first line of this paragraph is indented by 50 units, but the rest of the lines will not indent at all.
          </Paragraph>
      </Section>
         <Section>
          <Paragraph TextIndent="-50" Margin="50,20,0,0">
       The first line of this paragraph is not indented, but the rest of the lines will be indented by 50 units. The first line of this paragraph is not indented, but the rest of the lines will be indented by 50 units.
          </Paragraph>
      </Section>
         <Section>
          <Paragraph Margin="50,20,0,0">
       This paragraph is indented by 50 units, but the section is not indented at all. This paragraph is indented by 50 units, but the section is not indented at all. This paragraph is indented by 50 units, but the section is not indented at all.
          </Paragraph>
          <Paragraph Margin="100,0,0,0">
       This paragraph is indented by 100 units, but the section is not indented at all. This paragraph is indented by 100 units, but the section is not indented at all. This paragraph is indented by 100 units, but the section is not indented at all.
          </Paragraph>
      </Section>
         <Section Margin="50,20,0,0">
          <Paragraph Margin="0,0,0,0">
       This paragraph is not indented, but the section is indented by 50 units. This paragraph is not indented, but the section is indented by 50 units. This paragraph is not indented, but the section is indented by 50 units.
          </Paragraph>
          <Paragraph Margin="50,0,0,0">
       This paragraph is indented by 50 units, but the section is also indented by 50 units. This paragraph is indented by 50 units, but the section is also indented by 50 units. This paragraph is indented by 50 units, but the section is also indented by 50 units.
          </Paragraph>
      </Section>
         <Section Margin="50,20,0,0">
             <Section Margin="50,0,0,0">
              <Paragraph Margin="0,0,0,0">
           This paragraph is not indented, but it is in a nested section that is indented by 50 units and the outer section is also indented by 50 units - that makes 100 units total for this paragraph.
              </Paragraph>
          </Section>
      </Section>
  </FlowDocument>
</FlowDocumentScrollViewer>

WPF FlowDocuments - What, When, Why, How?

Jason Prickett — Wed, 07 Jan 2009 16:53:00 GMT

As I learn more and more about WPF, I am continually amazed at how much I don't know. I recently discovered FlowDocuments (look here for more info on the basics of FlowDocuments) and how wonderful they are. Okay, I knew about them a little, but I ignored them because I didn't think you could do very much with them other than present text to the user. Well how wrong I was!

Why?

I found my self using lots and lots of textblocks to display some information to the user. I was struggling with several limitations of textblocks: how they wrap depends on the container, databinding part of the text is not possible without databinding all of it, and there is no way to allow the user to select the text for copying to the clipboard. These limitations caused me to write lots of code to work around the issues and provide the user experience that I wanted. I had dozens of ValueConverters to format the bound data into the correct strings and even more code and XAML to get the text blocks to wrap appropriately.

What?

A colleague suggested that FlowDocuments might provide some answers, So dug into them and discovered a world of solutions to the problems that I faced. Flow Documents are kind of like HTML. In fact you can find lots of sites that compare the two if you search for it. Here are the features that drew me in and forced me to rewrite my entire interface to use FlowDocuments:

Selection and copying to the clipboard support is natural and free.
The memory foot print compared to all the controls that I was using before was a huge improvement and likewise the performance was better as well (although I didn't measure it).
For displaying text there is nothing better. You can easily indent, bold, align, wrap, etc.
Hyperlinks work properly only inside a FlowDocument.
If you use a FlowDocumentScrollViewer to display your flow document (this is what I used), you get Scrolling, Find, Print, and Zoom capabilities.

The one downside is that like textblocks there is not a simple way to bind data to the document. But for a read-only view of data, it is perfect.

When?

Based on my experience with FlowDocument so far, I would recommend using them anytime the number of textblocks outnumber the other controls on your window. You can also embed a flow document within another container control like a Grid. But I wouldn't recommend that unless you really need it.

How?

I will write more posts on how I am using flowdocuments and the special things I have learned, but here is a quick synopsis of how I used them in this particular case:

I replaced the TreeView that I had bound to my hierarchical data with a recursive method that added indented paragraphs to a section. After it's done, I simply add the section to the flowdocument. Indenting a paragraph is a little tricky, but that's a later post. Of course, the tree is no longer collapsible, but I didn't really need it to be anyway. The indentation was all I needed. I created my own value converters that could convert by data into paragraphs. That allowed my recursive function to be very generic.

I used Figures to have a right justified column of numbers associated with some but not all of the paragraphs in my hierarchy. There's not much info about Figures so I will probably make that one of my first posts after this one.

Paragraphs can have borders, so I used that fact to add some nice horizontal lines to the output that lined up the numbers on the right with there headers and grouped some of the paragraphs together.

One of the last things I did was to add in a way for the user to add additional text to certain areas. In one instance I added a button that simply created paragraphs for some objects in the hierarchy that are skipped by default. In other areas, I created my own kind of expander that has the look of a tree view item and adds additional paragraphs below itself. I called this last one an CollapsibleSection because I derived it from Section. I will definitely have a post on that one.

WPF - A Stretching TreeView

Jason Prickett — Tue, 05 Aug 2008 23:32:15 GMT

What is a stretching treeView?

Recently, I found the need to have a TreeView in my WPF application that was only a few levels deep. I didn't want a horizontal scrollbar to appear and I wanted the long text nodes to wrap. So, I invented the StretchingTreeView control.

Why couldn't I do this with a normal WPF TreeView?

Well, you can, but you have to replace the ControlTemplate for all the TreeViewItems. That's either a lot of XAML or a lot of code.

So, what exactly is the problem?

If you look at the default ControlTemplate for a TreeViewItem, you will see that it contains a grid with 3 columns. In the first column is the expander, in the second column is the Header of the TreeViewItem. And in the last column is nothing. The second column is set to a Width of Auto which means that it will size to its contents. The third column is set to a Width of Star which means it will grow and shrink with the width of the TreeView. No matter what you put in the Header of the TreeViewItem, it will never stretch to the right edge of the TreeView. And Since the Header column is set to Auto, it will never cause a TextBlock or anything else to wrap. Instead, if you turn off the horizontal scrollbar, your long text items simply get clipped at the right edge of the TreeView.

So, what's the code to fix it?

Well it was actually very simple. Once I found out that you can control what kind of Controls a TreeView creates for its items. By subclassing TreeView and overriding the methods GetContainerForItemOverride and IsItemItsOwnContainerOverride, you can control what types are created for your tree. This is especially important if you are databinding your tree to some hierarchy of objects and can't just create TreeViewItems directly. In any case here is the code...

    class StretchingTreeView : TreeView
    {
        protected override DependencyObject GetContainerForItemOverride()
        {
            return new StretchingTreeViewItem();
        }

        protected override bool IsItemItsOwnContainerOverride(object item)
        {
            return item is StretchingTreeViewItem;
        }
    }

    class StretchingTreeViewItem : TreeViewItem
    {
        public StretchingTreeViewItem()
        {
            this.Loaded += new RoutedEventHandler(StretchingTreeViewItem_Loaded);
        }

        private void StretchingTreeViewItem_Loaded(object sender, RoutedEventArgs e)
        {
            // The purpose of this code is to stretch the Header Content all the way accross the TreeView. 
            if (this.VisualChildrenCount > 0)
            {
                Grid grid = this.GetVisualChild(0) as Grid;
                if (grid != null && grid.ColumnDefinitions.Count == 3)
                {
                    // Remove the middle column which is set to Auto and let it get replaced with the 
                    // last column that is set to Star.
                    grid.ColumnDefinitions.RemoveAt(1);
                }
            }
        }

        protected override DependencyObject GetContainerForItemOverride()
        {
            return new StretchingTreeViewItem();
        }

        protected override bool IsItemItsOwnContainerOverride(object item)
        {
            return item is StretchingTreeViewItem;
        }
    }

Basically, all I do is create my own TreeViewItems that wait until they are loaded and then fix the Grid by removing the middle column. I don't like the fix, because it seems like a hack, but it's hardly any code. And that I like.

I hope this helps somebody out there!

Exploring WPF - Programmatically scrolling a treeview

Jason Prickett — Tue, 06 Nov 2007 00:37:20 GMT

Another one of the newest technologies released by Microsoft is WPF (Windows Presentation Foundation). This is a completely new way of thinking about User Interfaces. One of the things that I find the most interesting is the way that complex controls are created in WPF. Let's take a quick look at the TreeView control in WPF.

If you are used to the Windows Forms TreeView, you should probably make a point to forget everything that you know about it. The WPF TreeView is really a composite of other elements (it is not a wrapper around the Win32 TreeView - for better or worse - I think better!). To get the look that you want for a control, WPF provides a Style for the control that is made up of the other simpler elements that give it the appropriate look. The TreeView is visually made up of a Border, then a ScrollViewer, and then an ItemsPresenter. So, I really haven't investigated what an ItemsPresenter is yet, but you should get the idea... the "control" is made up of other elements that deal with the drawing and the control is left to deal with the behavior.

If you want to change the look of a TreeView, just change the style. You can change the border, remove the scroll viewer, or add any other elements you like.

But the real reason I wanted to write this post was to share the code that I had to write to programmatically scroll the treeview. Why would I do that? Well, I was implementing Drag n Drop on this particular TreeView and needed to scroll for the user when they were dragging near the bottom or top of the tree. Because you can change the Style of the TreeView, there isn't a built in way to get to the scrollviewer which really stinks. But, knowing that my control wouldn't change, I was able to create a simple property on my subclasses TreeView to get the scroll viewer and here it is:

        private ScrollViewer ScrollViewer
        {
            get
            {
                if (m_scrollViewer == null)
                {
                    DependencyObject border = VisualTreeHelper.GetChild(this, 0);
                    if (border != null)
                    {
                        m_scrollViewer = VisualTreeHelper.GetChild(border, 0) as ScrollViewer;
                    }
                }

                return m_scrollViewer;
            }
        }

As you can see, if you know your Visual tree, it is easy to get the ScrollViewer. Once I had the scrollviewer the logic to scroll the tree view was simple as well:

        internal void ScrollIfNeeded(Point mouseLocation)
        {
            if (this.ScrollViewer != null)
            {
                double scrollOffset = 0.0;

                // See if we need to scroll down
                if (this.ScrollViewer.ViewportHeight - mouseLocation.Y < 20.0)
                {
                    scrollOffset = 3.0;
                }
                else if (mouseLocation.Y < 20.0)
                {
                    scrollOffset = -3.0;
                }

                // Scroll the tree down or up
                if (scrollOffset != 0.0)
                {
                    scrollOffset += this.ScrollViewer.VerticalOffset;

                    if (scrollOffset < 0.0)
                    {
                        scrollOffset = 0.0;
                    }
                    else if (scrollOffset > this.ScrollViewer.ScrollableHeight)
                    {
                        scrollOffset = this.ScrollViewer.ScrollableHeight;
                    }

                    this.ScrollViewer.ScrollToVerticalOffset(scrollOffset);
                }
            }
        }

I won't go into a lot of explanation, but if the user is dragging the mouse 20 units (not pixels) from the top of the scroll area or 20 units from the bottom of the scroll area, I simple move the scroll area the appropriate direction by 3 units.

I hope this post helps someone out there trying to do the same sort of thing!