Elegant Log Window in WinForms C#

Question

I am looking for ideas on an efficient way to implement a log window for a windows forms application. In the past I have implemented several using TextBox and RichTextBox but I am still not totally satisfied with the functionality.

This log is intended to provide the user with a recent history of various events, primarily used in data-gathering applications where one might be curious how a particular transaction completed. In this case, the log need not be permanent nor saved to a file.

First, some proposed requirements:

• Efficient and fast; if hundreds of lines are written to the log in quick succession, it needs to consume minimal resources and time.
• Be able to offer a variable scrollback of up to 2000 lines or so. Anything longer is unnecessary.
• Highlighting and color are preferred. Font effects not required.
• Automatically trim lines as the scrollback limit is reached.
• Automatically scroll as new data is added.
• Bonus but not required: Pause auto-scrolling during manual interaction such as if the user is browsing the history.

What I have been using so far to write and trim the log:

I use the following code (which I call from other threads):

// rtbLog is a RichTextBox
// _MaxLines is an int
public void AppendLog(string s, Color c, bool bNewLine)
{
    if (rtbLog.InvokeRequired)
    {
        object[] args = { s, c, bNewLine };
        rtbLog.Invoke(new AppendLogDel(AppendLog), args);
        return;
    }
    try
    {
        rtbLog.SelectionColor = c;
        rtbLog.AppendText(s);
        if (bNewLine) rtbLog.AppendText(Environment.NewLine);
        TrimLog();
        rtbLog.SelectionStart = rtbLog.TextLength;
        rtbLog.ScrollToCaret();
        rtbLog.Update();
    }
    catch (Exception exc)
    {
        // exception handling
    }
}

private void TrimLog()
{
    try
    {
        // Extra lines as buffer to save time
        if (rtbLog.Lines.Length < _MaxLines + 10)
        {
            return;
        }
        else
        {
            string[] sTemp = rtxtLog.Lines;
            string[] sNew= new string[_MaxLines];
            int iLineOffset = sTemp.Length - _MaxLines;
            for (int n = 0; n < _MaxLines; n++)
            {
                sNew[n] = sTemp[iLineOffset];
                iLineOffset++;
            }
            rtbLog.Lines = sNew;
        }
    }
    catch (Exception exc)
    {
        // exception handling
    }
}

The problem with this approach is that whenever TrimLog is called, I lose color formatting. With a regular TextBox this works just fine (with a bit of modification of course).

Searches for a solution to this have never been really satisfactory. Some suggest to trim the excess by character count instead of line count in a RichTextBox. I've also seen ListBoxes used, but haven't successfully tried it.

Answer 1

I would say ListView is perfect for this (in Detail viewing mode), and its exactly what I use it for in a few internal apps.

Helpful tip: use BeginUpdate() and EndUpdate() if you know you will be adding/removing a lot of items at once.

Answer 2

If you want highlighting and color formatting, I'd suggest a RichTextBox.

If you want the auto scrolling, then use the ListBox.

In either case bind it to a circular buffer of lines.

Answer 3

The reason you're losing your color formatting is because you're copying your rich text box's text instead of its RTF text.

I'd suggest what Cheeso said and store your RTF text in a circular buffer of lines.

Answer 4

I recommend that you don't use a control as your log at all. Instead write a log collection class that has the properties you desire (not including the display properties).

Then write the little bit of code that is needed to dump that collection to a variety of user interface elements. Personally, I would put SendToEditControl and SendToListBox methods into my logging object. I would probably add filtering capabilities to these methods.

You can update the UI log only as often as it makes sense, giving you the best possible performance, and more importantly, letting you reduce the UI overhead when the log is changing rapidly.

The important thing is not to tie your logging to a piece of UI, that's a mistake. Someday you may want to run headless.

In the long run, a good UI for a logger is probably a custom control. But in the short run, you just want to disconnect your logging from any specific piece of UI.

Answer 5

I recently implemented something similar. Our approach was to keep a ring buffer of the scrollback records and just paint the log text manually (with Graphics.DrawString). Then if the user wants to scroll back, copy text, etc., we have a "Pause" button that flips back to a normal TextBox control.