Temat: Abstrakcyjna klasa bazowa własnej kontrolki
Zgadzam się. Żeby zmienić wygląd kontrolki nie trzeba tworzyć na nowo kontrolki. WPF jest tak zaplanowane, że kontrolki są
lookless - dzięki temu są gotowe, by z nimi cuda zrobić - dodawać animacje, dźwięki - cuda po prostu. Też nie wierzyłem, ale to prawda
Nie wierzę za to w inną rzecz - że ktoś jest w stanie wymyślić coś więcej - niż zmodyfikowany wyglądem ScrollBar.
Jeśli tak - to powinien jak najszybciej opatentować swój pomysł, bo być może miałby szansę zrewolucjonizować rynek zaskakująco odkrywczym interfejsem użytkownika.
Jeśli więc ktoś nie ma aspiracji, żeby podbijać rynek, powinien wziąć
lookless control i nauczyć się dopasowywać jej wygląd i zachowanie (sic!) do swych potrzeb i fantazji. Doprawdy - nie ma takiej rzeczy, której nie da się zrobić z kontrolką WPF.
UserControl bardziej stosuje się jako pojemnik na inne kontrolki. Kiedyś pisałem kontrolkę do zaznaczania czasu na siatce. Oparłem to właśnie na UserControl, bo mi było wygodnie i prosto.
Ciekawostka - UserControl potrafi pomieścić wszystko to co Window - to może być przydatne, bo można zmienić okno w kontrolkę zmieniając tylko tag XAML i to co kiedyś było oknem, osadzić w innym oknie - już jako kontrolkę.
Jeśli chcesz coś zrobić na szybko - kalendarz z przyciskami, kontrolkę wyświetlające animacje 3D załadowaną dzięki informacji z property Filename itd. - użyj UserControl.
Chcesz mieć własny wygląd ScrollBar-a - zmień template.
Chcesz dodać dodatkowe eventy do ScrollBar-a (np. zdarzenie, które zachodzi gdy przesunąłeś ScrollBar o 100 jednostek)?
Możesz osadzić ScrollBar choćby w UserControl, podpiąć się z poziomu UserControl pod zdarzenie w stylu OnChange (z głowy wymyślam) i gdy kod w OnChange odkryje zmianę o 100 jednostek, wtedy UserControl zawoła kod podpięty pod zdarzenie On100UnitsChange
Tak dla przykładu. UserControl oczywiście zawiera dużo śmieciowatych properties, których nie użyjesz, więc być może warto to osadzić w jakiejś innej, "kontenerowatej" kontrolce.