Click here to Skip to main content
15,893,588 members
Please Sign up or sign in to vote.
0.00/5 (No votes)
See more:
I have built a program that loads Xaml into a RichTextBox, and then goes through the text sentence by sentence, using Regex to find words against a glossary.

From the Regex Matches, I then create TextRanges (from TextPointers, determined by the Match.Index, by counting from the Document.ContentStart), and I keep these in a List<TextRange>.

I then Highlight each TextRange in the List by using
C#
TextRange.ApplyPropertyValue(TextBlock.BackgroundProperty, myHighlightBrush)
.

This procedure has to be done for each sentence, so each time, I clear the List and then recalculate the TextPointers for the next sentence.

(The TextRanges need to be kept in the running List in order to access the text of those ranges later).

After a lot of trial-and-error I've gotten the program to do exactly what I want, but there is a problem:
When I use it continuously for more than an hour or so, the procedure becomes progressively slower, and through some debugging I've been able to narrow the slowing part to the actual highlighting of the TextRanges.

If the program is closed and reopened, and started from the previous point, the highlighting speed is acceptable again, and predictably after an hour or so, it starts to become maddeningly sluggish again.

What I have tried:

Some things I have tried are:
1) Run.Background highlighting instead of TextBlock, i.e.
C#
TextRange.ApplyPropertyValue(Run.BackgroundProperty, myHighlightBrush);


2) Reinstantiating the List instead of clearing it, i.e.
C#
List<TextRange> ranges = new List<TextRange>();


But it seems not to have any effect in terms of progressive slowing.

What I'm wondering is, what is happening to all of those TextPointers I've been creating along the way? I can't find any way to dispose of the old ones, so are they automatically disposed of? If not, could they be slowing things down, since presumably the RichTextBox has to do heuristic calculations for each TextPointer whenever a change is made to it. Or maybe all these TextPointers are just causing memory leaks?

Is clearing the List enough to rid the RichTextBox of the previous TextPointers and TextRanges?

I can't find any information on the net about what happens to TextPointers after you're done using them...
Posted
Updated 22-Mar-20 6:38am
Comments
Richard MacCutchan 22-Mar-20 12:43pm    
When you clear the list do you first clear all the TextPointers and TextRanges in the list? if they are still pointing at some data then the GC will not collect them.
mycenean 22-Mar-20 13:35pm    
When I clear the List, I have no idea how to "clear" the TextPointers/TextRanges, would that mean just setting them to null?
Richard MacCutchan 22-Mar-20 13:41pm    
Yes, that clears their reference counters so they can be removed. Also if the data they are referencing is no longer being used then that memory space will be freed also.
mycenean 22-Mar-20 13:44pm    
Ok, I will try setting them to null before clearing the List, and see if the speed issue resolves.
As to whether the data they are referencing is still being used or not, I would guess it is still being used, because the function of a TextPointer is to reference a location in the text of a FlowDocument, and the FlowDocument with its text still exists, of course.
mycenean 23-Mar-20 1:18am    
Hi, after trying another several runs (= several hours), this seems to not have solved the problem unfortunately.
(I modified the code so that all the TextRanges in the List are set to null before clearing the List).
Of course, I'm just assuming this is a TextPointer issue, I'm beginning to wonder if it isn't, although it does seem to be the most likely reason.
Any idea what else could be slowing down highlighting in a RichTextBox? People have been complaining about the notoriously slow formatting in WPF RTB, but at program startup it performs reasonably fast, it's just after more than an hour of usage that it begins to get sluggish.

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



CodeProject, 20 Bay Street, 11th Floor Toronto, Ontario, Canada M5J 2N8 +1 (416) 849-8900