OK, that is what I was thinking. I'm using the INotifyPropertyChanged event also, for the exact same reason, the potential binding properties don't have change events.



Thanks!

There are a few places where we update the data from a background thread, and so we wanted the changed event to be raised on the main thread.  It doesn't have to be thread-safe, but it would require is to make the handlers thread-safe, so this was the simplest route.  On your own custom controls, you don't need to make them thread-safe unless you really need it

As for the reason for the INotifyPropertyChanged event, we had to use it because there is no RtfChanged event so if you want to bind to the property, the INotifyPropertyChanged is required to make the binding two-way.

I noticed that when you implemented the INotifyPropertyChanged interface in the SF RichTextbox control, it looks like you made it thread safe. Is that correct? Why does it need to be thread safe?