Можно ли использовать во взломе Silverlight NotifyCollectionChangedEventArgs для поддержки нескольких элементов?

Версия Silverlight NotifyCollectionChangedEventArgs отличается от полной версии платформы тем, что не принимает несколько (добавленных, измененных, удаленных) элементов. Конструкторы, которые принимают списки, на самом деле отсутствуют, поэтому похоже, что Microsoft намеревалась заблокировать такое использование. В самом деле, если вы передаете коллекцию элементов, они просто вкладываются как первый элемент внутренней коллекции.

Тем не мение! Поскольку члены NewItems и OldItems относятся к типу IList, они не являются неизменяемыми и могут быть увеличены. Я сделал следующий помощник, чтобы проверить эту идею:

    private NotifyCollectionChangedEventArgs CreateEventArgsWithMultiple(NotifyCollectionChangedAction action, IEnumerable items, int newStartingIndex)
    {
        NotifyCollectionChangedEventArgs eventArgs = null;

        foreach (var item in items)
        {
            if (eventArgs == null)
            {
                eventArgs = new NotifyCollectionChangedEventArgs(action, item, newStartingIndex);
            }
            else
            {
                eventArgs.NewItems.Add(item);
            }
        }

        return eventArgs;
    }

Я еще не видел никаких проблем, но мне нужен опыт и отзывы об этом конкретном уголке Silverlight. Стоит ли мне беспокоиться о таких добавлениях, или просто использовать сброс?

Кстати, это на Windows Phone 7.1 (Mango).

Изменить: следить за комментарием Эрно. Microsoft сообщает в эта (плохо сформулированная) страница документации Silverlight в MSDN, что "в целом" можно предположить, что NewItems имеет только один элемент, и даже предлагает сокращение использования NewItems [0] для доступа к нему. Таким образом, они сохраняют подпись IList для «совместимости», но затем продолжают терять значение типа. Неутешительно.


silverlight inotifycollectionchanged
person CÅdahl    schedule 20.12.2011    source источник
comment
поэтому похоже, что Microsoft намеревалась заблокировать это использование, возможно, у Microsoft просто не было времени добавить его, или это одна из тех областей, которые они использовали для уменьшения размера фреймворка.   -  person Emond Erno    schedule 20.12.2011
comment
Но это также может означать, что код потребляющего в Silverlight предполагает наличие только одного элемента. Это было бы довольно плохо. Я мог убедиться, что мои собственные варианты использования работают (например, привязка к ItemsSource), но мне любопытно, пробовал ли кто-нибудь еще это и столкнулся с проблемами.   -  person CÅdahl    schedule 20.12.2011
comment
В самом деле, это может означать что угодно. Я просто хотел предупредить о поспешных выводах.   -  person Emond Erno    schedule 20.12.2011

Ответы (1)


arrow_upward
1
arrow_downward

Я не сталкивался ни с какими проблемами, но ответ - «Не делай этого!» (если только вы не передаете аргументы только написанному вами коду).

Причина (как было сказано в комментариях) в том, что в Silverlight может быть код, предполагающий наличие только одного элемента. Даже если этого не произойдет сегодня, может быть завтра, и вы определенно не хотите, чтобы ваше приложение сломалось, когда выйдет какая-то новая версия Silverlight, которая в большей степени полагается на это предположение.

person RobSiklos    schedule 20.12.2011