Переключитесь от использования свойства Text RichTextBox к свойству Rtf. Это достигает результата, которого я добиваюсь ...
Спасибо всем
Фундаментальное качество, которое отличает стекируемые модификации (поскольку терминология в любом случае используется в scala), заключается в том, что "super" динамически зависит от того, как подмешивается признак, тогда как в целом super - это статически определенная цель.
Если вы напишете
abstract class Bar { def bar(x: Int): Int }
class Foo extends Bar { def bar(x: Int) = x }
, тогда для Foo "super" всегда будет Bar.
Если вы напишете
trait Foo1 extends Foo { abstract override def bar(x: Int) = x + super.bar(x) }
, тогда для этого метода super останется неизвестным до тех пор, пока класс не будет создан.
trait Foo2 extends Foo { abstract override def bar(x: Int) = x * super.bar(x) }
scala> (new Foo with Foo2 with Foo1).bar(5)
res0: Int = 30
scala> (new Foo with Foo1 with Foo2).bar(5)
res1: Int = 50
Почему это интересно? Наглядным примером могут быть данные, которые вы хотите сжать, зашифровать и поставить цифровой подписью. Возможно, вы захотите сжать, затем зашифровать, а затем подписать, или вы можете захотеть зашифровать, затем подписать, затем сжать и т. Д. Если вы проектируете свои компоненты таким образом, вы можете создать экземпляр настраиваемого объекта с точно такими битами, которые вы хотите организовать так, как вы хотите.
Я просмотрел презентацию Real-World Scala , где также используется термин наращиваемые модификации . По-видимому, это черты, которые вызывают супер-метод при переопределении, по сути добавляя функциональность, а не заменяя ее. Таким образом, вы накапливаете функциональность с помощью признаков, и ее можно использовать там, где в Java мы часто используем аспекты. Trait играет роль аспекта, переопределяя "интересные" методы и добавляя определенные функции, такие как ведение журнала и т.д., а затем вызывает super и "передает мяч" следующему трейту в цепочке. НТН.