Question

I have two controls. The XAML’s are big and very similar. One difference is this: they contain a listbox, in one control, it’s bound to {StaticResource X}, and is multiselect, the other is bound to {StaticResource Y}, and is not multiselect. The code-behinds are also very similar. How should I combine these two classes into one? I thought about creating a base class and deriving my 2 controls from it, but I have no idea how to do that with XAML. I know I could make it easier if I set the differing properties in code instead of XAML (in which case the XAML’s would become identical), but let’s consider that plan B. Silverlight has no StyleSelector, it seemed like a possible solution though. Maybe VisualStateManager could do it, except it sounds bad, because my problem has nothing to do with visuals, but maybe I could define 2 states anyway. Except I think SL doesn’t support binding in style definitions. Tough question for a beginner like me…

Answer 1

So, to sum it up, I want one control which can work in somewhat different modes, or states. The mode can affect XAML properties and code logic, too.

It seems like VisualStateManager is very limited in which properties it can manipulate. But when the differences are only visual, it’s the best choice.

When there are other differences in XAML, then the obvious choice is to omit those properties from XAML and set them in code, like in the ctor. A nicer way is to expose those properties as dependency properties in code, bind to those properties in the XAML of the user control, and then you can specify those properties in other XAML’s where you use this user control. When your control doesn’t care what’s in those properties, then it’s a good design choice, too. In my case, though, when setting up those differing properties should be the responsibility of the user control itself, not its parent, and I want to expose a single mode property only, it’s not good.

For this case, the best way I found so far is this:

• create a normal user control (XAML+code), expose the differing properties (simple, not DP’s) and bind to them in XAML
• make this user control abstract, and possibly some properties, too
• for each different mode the control needs to support, derive a class from this base control (code only, no XAML), provide implementations for the abstract properties
• instead of using the base control in other places, use one of the derived implementations

This way, you can easily specify from outside which mode you want your control to work in. The drawback is that it’s not easy to change the mode, since it’s not a property you need to change but the type and instance of the control.

And finally, when there are code logic differences, too, then one way is exposing a mode property, or using the abstract class method I described above. For example, a button click handler function can be abstract, too.