<li>ICSharpCode.AvalonEdit.CodeCompletion: <code>CompletionWindow</code>—shows a drop-down list for code completion</li>
<li>ICSharpCode.AvalonEdit: <code>TextEditor</code>— the main control that brings it all together</li>
</ul>
@ -192,8 +193,10 @@ The last step in the pipeline is the conversion to one or more <code>System.Wind
@@ -192,8 +193,10 @@ The last step in the pipeline is the conversion to one or more <code>System.Wind
<p>
The "element generators", "line transformers" and "background renderers" are the extension points; it is possible to add custom implementations of
them to the <code>TextView</code> to implement additional features in the editor.
<!--
<p>
The extensibility features of the rendering namespace are discussed in detail in the article "AvalonEdit Rendering". (to be published soon)
-->
<h2>Editing</h2>
@ -204,7 +207,7 @@ You can customize the text area by modifying the <code>TextArea.DefaultInputHand
@@ -204,7 +207,7 @@ You can customize the text area by modifying the <code>TextArea.DefaultInputHand
WPF input bindings in it. You can also set <code>TextArea.ActiveInputHandler</code> to something different than the default
to switch the text area into another mode. You could use this to implement an "incremental search" feature, or even a VI emulator.
<p>
The text area has the <code>LeftMargins</code> property - use it to add controls to the left of the text view that look like
The text area has the <code>LeftMargins</code> property – use it to add controls to the left of the text view that look like
they're inside the scroll viewer, but don't actually scroll. The <code>AbstractMargin</code> base class contains some useful code
to detect when the margin is attached/detaching from a text view; or when the active document changes. However, you're not forced to use it;
any <code>UIElement</code> can be used as margin.
@ -303,13 +306,13 @@ and yet usually requires only a few KB of memory even for large code files.
@@ -303,13 +306,13 @@ and yet usually requires only a few KB of memory even for large code files.
<p><i>On-demand</i> means that when a document is opened, only the lines initially visible will be highlighted. When the user scrolls down, highlighting will
continue from the point where it stopped the last time.
If the user scrolls quickly, so that the first visible line is far below the last highlighted line, then the highlighting engine still has to process all the
lines in between - there might be comment starts in them. However, it will only scan that region for changes in the span stack; highlighting rules will not
lines in between – there might be comment starts in them. However, it will only scan that region for changes in the span stack; highlighting rules will not
be tested.
<p>The stack of active spans is stored at the beginning of every line. If the user scrolls back up, the lines getting into view can be highlighted immediately
because the necessary context (the span stack) is still available.
<p><i>Incrementally</i> means that even if the document is changed, the stored span stacks will be reused as far as possible. If the user types <code>/*</code>, that would
theoretically cause the whole remainder of the file to become highlighted in the comment color. However, because the engine works on-demand, it will only update the
span stacks within the currently visible region and keep a notice 'the highlighting state is not consistent between line X and X+1', where X is the last line
span stacks within the currently visible region and keep a notice 'the highlighting state is not consistent between line X and line X+1', where X is the last line
in the visible region. Now, if the user would scroll down, the highlighting state would be updated and the 'not consistent' notice would be moved down.
But usually, the user will continue typing and type <code>*/</code> only a few lines later. Now the highlighting state in the visible region will revert to the
normal 'only the main ruleset is on the stack of active spans'. When the user now scrolls down below the line with the 'not consistent' marker;
@ -323,15 +326,98 @@ The memory usage of the highlighting engine is linear to the number of span stac
@@ -323,15 +326,98 @@ The memory usage of the highlighting engine is linear to the number of span stac
This allows the highlighting engine to store the span stacks for big code files using only a tiny amount of memory,
especially in languages like C# where sequences of <code>//</code> or <code>///</code> are more popular than <code>/* */</code> comments.
<h2>Code Completion</h2>
<p>AvalonEdit comes with a code completion drop down window.
You only have to handle the text entering events to determine when you want to show the window; all the UI is already done for you.
Both the content and the description shown may be any content acceptable in WPF, including custom UIElements.
You may also implement custom logic in the <code>Complete</code> method if you want to do more than simply inserting the text.
The <code>insertionRequestEventArgs</code> can help decide which kind of insertion the user wants - depending on how the insertion
was triggered, it is an instance of <code>TextCompositionEventArgs</code>, <code>KeyEventArgs</code> or <code>MouseEventArgs</code>.
<h2>History</h2>
<p>Keep a running update of any changes or improvements you've made here.
<ul>
<li>August 13, 2008: Work on AvalonEdit started</li>
<li>November 7, 2008: First version of AvalonEdit added to SharpDevelop 4.0 trunk</li>
<li>June 14, 2009: The SharpDevelop team switches to SharpDevelop 4 as their IDE for working on SharpDevelop; AvalonEdit starts to get used for real work</li>
<li>October 4, 2009: This article first published on The Code Project</li>
</ul>
<p><b>Note: although my sample code is provided under the MIT license, ICSharpCode.AvalonEdit itself is provided under the terms of the GNU LGPL.</b>