SyntaxEditor for WPF - Batching up replace operations

The past several days we’ve been working on a batch update feature.  Before I get into what that means, let’s first discuss how SyntaxEditor for WinForms works. 

The Problem

Each call to SyntaxEditor 4’s Document.InsertText, DeleteText, and ReplaceText methods is its own atomic unit, meaning that UI updates and a lot of other processing occurred after each individual change.  While normally this is ok, sometimes when doing thousands of sequential replace operations in a document, it can take a bit to update.

The Solution

In the next generation text model that we’re prototyping for our SyntaxEditor for WPF control (and will eventually migrate the WinForms control to use it as well), we’ve made a number of improvements for this particular problem.

In the new model, the document class still has InsertText, DeleteText, and ReplaceText methods.  If you call those directly then they will be executed like in the SE4 model.  However you now have an option to call a method named BeginTextChange.  What this does is allows you to start a “group” of replace operations.  Each BeginTextChange must eventually be followed by a corresponding EndTextChange.  The calls may be nested too.  Upon the final EndTextChange call, the batch of replace operations are executed as a single atomic unit.

The object model is such than an ITextChange is a thing that contains some high level data and a list of ITextChangeOperation objects.  Each ITextChangeOperation represents a single replace operation.  So when the document’s TextChanged event fires, it passes along in its event arguments the ITextChange.

A Real-World Sample

As a real world example, say you are going to be performing 1000 replace operations immediately to maybe properly indent 1000 lines of code, so one replace operation for each line of code.  Here is an ideal place to use the Begin/EndTextChange model.  You would start with a call to BeginTextChange, then call ReplaceText for each of your 1000 replace operations, then call EndTextChange.  At the time you call EndTextChange, the single ITextChange (containing 1000 ITextChangeOperation objects) that has been cached up is passed along to the undo mechanism, UI, etc. via the document’s TextChanged event.  Therefore for all these replace operations, the UI and other things only update once, thereby really speeding up response time.

The Bottom Line

I know that a lot of you are anxious to get your hands on SyntaxEditor for WPF and it’s taking a bit to get ready, however I hope that by posting information like this, you can see we’re really focusing on improving core fundamental structures and methodologies.  These things are going to open up a whole new realm of possibilities for the control.  While this does delay the initial release, in the long run we’ll have a far better and more robust product than any of our competition.