Wednesday, January 25, 2012

"Building a large text file editor" Series - Part 1 of x

Windows and .NET Programming - Building a large text file editor – Part I

"The basic idea behind a large file viewer is that you can’t load a very large file into a TextBox or RichTextBox control because the memory usage as well as the time to load the file will be enormous. Moreover, the user can only see a very small portion of the file on the screen at once, so it doesn’t make sense to load all the data in the file at once.

As such, what is needed from a large file viewer is to only display some small parts of the file in order to fill at least a screen. This is pretty straightforward and will be addressed in the second post. What is a bit more complex is to enable the user to edit the file (i.e. make insertions and deletions). The problem with editing the file is that edits need to be taken into account when computing the position in the stream. If the user deletes say the first 10 characters and then wants to read two characters at offset 4, what actually needs to be read is the two characters at offset 14 from the original file:

  • Original string: "0123456789abcdefgh"
  • String after deleting 10 characters: "abcdefgh"
  • Character at offset 4 (zero-based): "e"
  • Offset in initial string: 14.

Obviously, things get more complicated when the user starts to randomly delete and insert text at various locations in the file.

The solution I’m proposing is the class RevisionStream (see attached code). This class is wrapper around the FileStream class and supports four public methods:

  • AddDeletion – the caller signals that a deletion has been made by the user
  • AddInsertion – the caller signals that the user has inserted some text
  • Read – reads some bytes from the revised stream
  • SaveTo – saves revised stream to file

The basic idea behind this approach is that normally the largest part of the text will remain identical to the original stream and only some minor changes will be done by the user. So it makes sense to leave the original text on disk and only load to memory the parts that we need together with the changes the user makes.



I saw this and thought, "Wow, what a cool series... I can't wait for the rest." What does thinking that say about me? LOL


I think this is a dev-cool sounding series and I appreciate that he's already attached the source code... ;)

No comments: