Of course you are right: polling by timer… bad idea. Of course, you should not do it.
Here is my pitch: where is your logic? Follow me: if you are already ready to handle some events to update the properties, why not looking for some other events, more suitable ones. But what events? Apparently, only those which change anything essentially. The main problem with polling is: nothing has changed to the control content, but you are still polling for possible change, which is bad. And what events could possibly change the content of this control? Of course, input events. If the user does not input anything (including deletion of some text/objects), nothing is changed, nothing to look for.
Are you getting the idea? ;-)
[EDIT]
Let's make a next step. Can we choose just one event, the only one worth handling for your purposes? This is the event
SelectionChanged. Even better, you can override the virtual method
OnSelectionChanged:
http://msdn.microsoft.com/en-us/library/system.windows.forms.richtextbox.selectionchanged.aspx[
^],
http://www.codeproject.com/script/Reputation/List.aspx?mid=2291164[
^].
You cannot possible change the content of the control without changing the selection; even of you never select anything, if you move the caret, it means the property
SelectionStart is changes. This is just the selection, I tell you.
Why this event is so good? You are not risking to fall into an infinite recursion. If you do you highlighting, you don't change selection.
But if you have some algorithm changing selection, you should switch off the handling inside handling (use some flag which should be you control's property), change selection inside the handler, and restore processing flag after you are done. In other words, make it non-reentrable.
Problem solved.
Good luck,
—SA
Submit an article or tip