A Universal WPF Find / Replace Dialog

• Download source - 410.24 KB

Introduction

This article describes a WPF Find/Replace dialog, which is designed to work with various types of text editor controls, in particular the AvalonEdit TextEditor. Furthermore, it supports multiple document interfaces. Here is a screenshot:

Using the Code (SDI & Code Behind Example)

For a single document editor, the Find/Replace dialog can be used as follows:

FindReplace.FindReplaceMgr FRM = new FindReplace.FindReplaceMgr();
public MainWindow()
{
    InitializeComponent();
    FRM.CurrentEditor = new FindReplace.TextEditorAdapter(MyTextEditor);
    FRM.ShowSearchIn = false;
    FRM.OwnerWindow = this;

    CommandBindings.Add(FRM.FindBinding);
    CommandBindings.Add(FRM.ReplaceBinding);
    CommandBindings.Add(FRM.FindNextBinding);
}

Here, it is assumed that you are using an AvalonEdit TextEditor control with name MyTextEditor.

Using the Code (MDI & XAML Example)

Next, let us consider the multiple document (MDI) case. Usually, there will be a list of views, together with a current view object. FindReplaceMgr can be instantiated in XAML as follows:

<Window.Resources>
   <my:MyViewData x:Key="ViewData" />
   <FR:IEditorConverter x:Key="IEC" />
   <FR:FindReplaceMgr x:Key="FRep" InterfaceConverter="{StaticResource IEC}" 
     Editors="{Binding Source={StaticResource ViewData}, Path=Views}"
     CurrentEditor="{Binding Source={StaticResource ViewData}, 
	Path=ActiveView, Mode=TwoWay}" />
</Window.Resources> 

Here, I assume that MyViewData is a class which contains a list of view objects Views and a view object CurrentView. The member InterfaceConverter of the FindReplaceMgr contains a converter, which takes a view object, and returns a FindReplace.IEditor interface, through which the FindReplaceMgr accesses the view. The built-in converter FindReplace.IEditorConverter accepts "the usual" editor controls. If you have a custom view class, you have to write a custom converter, but this is not much work, see below.

Abstracting a Text Editor Control

I wanted the Find Replace manager to be independent from any specific editor control implementation. Hence, all access to the editor control is channeled through the following interface:

public interface IEditor
{
    string Text { get; }
    int SelectionStart { get; }
    int SelectionLength { get; }
    void Select(int start, int length);
    void Replace(int start, int length, string ReplaceWith);
    void BeginChange();
    void EndChange();
}

The interface members are more or less self-explanatory. The BeginChange and EndChange methods are called before and after a replace all operation, allowing the editor to handle all replacements as a single undo group. There are predefined adapters for the AvalonEdit TextEditor, the WPF RichTextBox, the Windows Forms TextBoxBase, and the WPF TextBox (for the latter one, see the remark below). For example, in the SDI case, you can wire a WPF RichTextBox to the FindReplaceMgr with the following one-liner:

FRM.CurrentEditor = new RichTextBoxAdapter(MyRichTextBox);

MDI and Compatibility (more or less) with MVVM

My goal was to be able to integrate the FindReplaceMgr with few lines of code into "the typical" MVVM based MDI application. Such an application has typically a List of views somewhere, together with a variable specifying the current (active) view. Issues to be taken into account are the following:

• The FindReplaceMgr must be able to change the active view while searching through multiple documents.
• The FindReplaceMgr must know the active view to search in the right document.
• The view objects are typically of some user defined types.
• The rest of the application should not need to "know about" FindReplaceMgr (i.e., no changes to the view or view model should be necessary.)

My solution is as follows: The FindReplaceMgr has dependency properties Editors and CurrentEditor, which are to be bound to the view list and active view object. Here, the views can be any object (no special type assumed). When the view needs to be accessed for searching, FindReplaceMgr does the following:

1. It checks whether the CurrentEditor implements the IEditor interface. If it does, it is accessed through this interface.
2. Otherwise, it resorts to its InterfaceConverter member to convert the view object into an IEditor interface.

Hence, if you have custom view objects, you have two choices:

1. Implement IEditor in your view.
2. Write a custom converter. Usually, this amounts to just instantiating a pre-defined adapter on the editor control residing in your view object.

For example, the built-in converter looks as follows:

public class IEditorConverter : IValueConverter
{
    object IValueConverter.Convert(object value, Type targetType, object
               parameter, CultureInfo culture)
    {
        if (value is TextEditor)
            return new TextEditorAdapter(value as TextEditor);
        else if (value is TextBox)
            return new TextBoxAdapter(value as TextBox);
        else if (value is RichTextBox)
            return new RichTextBoxAdapter(value as RichTextBox);
        else if (value is WindowsFormsHost)
            return new WFTextBoxAdapter(
                  (value as WindowsFormsHost).Child 
                      as System.Windows.Forms.TextBoxBase);
        else return null;
    }

    object IValueConverter.ConvertBack(object value, Type targetType,
           object parameter, CultureInfo culture)
    {
        throw new NotImplementedException();
    }
}

Handling Commands

Typically, an application providing find/replace functionality binds to ApplicationCommands.Find, etc. I wanted this to be doable without having the user of FindReplaceMgr write command handlers and proxy the call to FindReplaceMgr. My solution is to expose three CommandBindings as properties of FindReplaceMgr, namely:

For example, you can wire up the commands to using the following XAML code (for the alternative version in C# code, see the SDI example above):

<Window.CommandBindings>
    <my:StaticResourceEx ResourceKey="FRep" Path="FindBinding" />
    <my:StaticResourceEx ResourceKey="FRep" Path="ReplaceBinding" />
    <my:StaticResourceEx ResourceKey="FRep" Path="FindNextBinding" />
</Window.CommandBindings>
<Window.InputBindings>
    <KeyBinding Key="F3" Modifiers="Shift" Command="Search" 
	CommandParameter="something" />
</Window.InputBindings>

Here, I use the markup extension StaticResourceEx from here to bind to the resource's members.

Remarks About the Native WPF Text Editors

The native WPF text editors TextBox and RichTextBox are not so easy to use with a find replace dialog, since they do not have a HideSelection property. The workarounds I found on the web did not work in the present setup. (Here, the focus is stolen by another window instead of another control on the same window.) The RichTextBox adapter circumvents this by coloring the currently selected text yellow. Here is the code sample:

public class RichTextBoxAdapter : IEditor
{
    ...
    TextRange oldsel = null;
    public void Select(int start, int length)
    {
        TextPointer tp = rtb.Document.ContentStart;
        rtb.Selection.Select(GetPoint(tp, start), GetPoint(tp, start + length));
        rtb.ScrollToVerticalOffset(rtb.Selection.Start.GetCharacterRect
			(LogicalDirection.Forward).Top);
        rtb.Selection.ApplyPropertyValue(TextElement.BackgroundProperty, 
			Brushes.Yellow);
        oldsel = new TextRange(rtb.Selection.Start, rtb.Selection.End);
        rtb.SelectionChanged += rtb_SelectionChanged;            
    }

    void rtb_SelectionChanged(object sender, RoutedEventArgs e)
    {
        oldsel.ApplyPropertyValue(TextElement.BackgroundProperty, null);
        rtb.SelectionChanged -= rtb_SelectionChanged;
    }
    ...
}

For the TextBox this is not possible, and I do not know how to circumvent, except the lazy solution: Use another control type, e.g., AvalonEdit (highly recommended) or the Windows Forms TextBox.

Some Licensing Issues

Note that the AvalonEdit TextEditor, and the library ICSharpCode.AvalonEdit.dll that I provide with the download for convenience are protected by the GNU Lesser General Public License (LGPL), and are explicitly NOT distributed under the CodeProject Open License. If you use these files in your project, you have to observe the restrictions imposed by the LGPL. However, note that the class FindReplaceMgr does not use, and contains no reference to the aforementioned library.

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)