Restrict the compile-time type of an ItemsControl's children

Question

I know this question has been asked before. I'm not satisfied with answer which was given. I'm looking for a compile-time solution. Is there a way to say hide the Items and ItemSource members without breaking the functionality of the class or is this not expected functionality? For example, could I create an ItemsControl<T> via reflecting ItemsControl and changing code or how could I go about achieving this?

To elaborate, I'm making an SlideShow control to display images in a slide show. It inherits from ItemsControl as it would have multiple children, but I would like to restrict it's children to Image objects only because I need access to these objects. I would like to enforce this restriction at compile time so I can safely access specific Image members without worrying what type the children are.

Answer 1

I figured it out. There is a control in the Windows Phone Toolkit that has the exact same behavior I am looking for. The TiltEffect dependency object enforces it's parent type at compile time. "Property IsTiltEnabled does not support values of type ..." I just have to do the same, but for the Children of my control.

What you need to do, more specifically is change the Items (through ItemsSource...) of the ItemsContorl to be a strongly typed collection, e.g. an ObservableCollection

Answer 2

I'm not very experienced in WPF but in plain C# I'd just delegate control.

For instance, if I was trying to restrict the objects I could add to an ArrayList, I'd do something like:

public class ArrayListDemo
{
    private ArrayList innerList;

    public ArrayListDemo()
    {
        innerList = new ArrayList();
    }

    public int Add(string str)
    {
        return innerList.Add(str);
    }

    public void Remove(string str)
    {
        innerList.Remove(str);
    }

    public string this[int index]
    {
        get
        {
            return innerList[index] as string;
        }
        set
        {
            innerList[index] = value;
        }
    }

    public static implicit operator ArrayList(ArrayListDemo stringArrayList)
    {
        return stringArrayList.innerList;
    }
}

This lets me write my own implementation of methods while not requiring me to overload ALL the methods. Having the implicit cast available means the compiler will know that our object can be used in place of the object we're overriding. Again, I don't know if this is something you can do with WPF or if the work involved overriding and delegating your calls is simply too complicated but I thought I'd point out the approach in case it's usable.

Answer 3

What "Special Behavior" do you need handled that iterating through the items needs to be done inside the control?

You can't use generics in XAML (yet, though you can MAKE it work in a limited way), so whatever you DO design will ONLY ever be able to handle one type of object, in your case Image. How is this more reusable that binding whatever type you want at runtime?

What is wrong with creating a UserControl to handle your slideshow functionality, rather than trying to force a control type not meant for what you're doing into it?

Why are you iterating through the Items property at all? It really seems to be designed to be used mainly by the underlying WPF system, not by the client. What functionality are you getting from doing that that cannot be achieved through simple binding?