Dispatcher.Invoke висит, когда ListCollectionView контролирует коллекцию

Question

Моя проблема очень похожа на упомянутую проблему in this post. По сути, Invoke висит (только при запуске вне отладчика). Я думаю, что это связано с вложением вызовов Invoke.

Я использую MVVM Light, и я пробовал две реализации многопоточного дружественного ObservableCollection - I've used this one for ages и недавно попытался упростить до this version. Последнее казалось лучше, пока оно не сработало с «принадлежащим этому потоку» InvalidOperationException. И, глядя на мою копию первого, похоже, что я проглатываю исключения. Капризный капризный. Это послужило бы причиной того, что собственность изменила «неудачи».

Это поток операций, который является хлопотным. Почти во всех точках я пробовал перемещать вещи в нить ui или перемещать их из нити ui. Мне удалось отложить зависание, но за счет имущества изменились сбои.

• запрос приходит из нити через WCF к первичному ViewModel
• Запрос разобранного (я пробовал и на фоновом потоке и вызов основному потоку) объекта
• ReportEntry извлекается из базы данных
• Отображается сообщение, отправленное в пользовательский интерфейс через Messenger, запрашивающий диалоговое окно редактирования.
• Главное окно обрабатывает сообщение, вызывается IEditableObject.BeginEdit и отображается диалог редактирования.
• По возвращении вызывается действие обратного вызова Messenger.
• Теперь ReportEntry готов к добавлению в соответствующую коллекцию. В MainViewModel есть коллекция FileViewModels, каждая из которых имеет коллекцию ReportViewModels.
  • Модели ReportViewModels обычно создаются с помощью FileViewModel, наблюдая за событиями CollectionChanged коллекции FileModel. Я пробовал обходить это, чтобы избежать больше гнездования, но безрезультатно.

Именно в этот момент, что мое приложение либо виснет (если я в первую очередь операционный в основном потоке) или CollectionChanged события из строя вследствие нарезания резьбы, в зависимости от того, как я переехал вещи между потоками.

Когда приложение зависает, оно находится в ожидании, вызванном из Invoke, в соответствии с отладчиком, который я прикрепляю.

О, и я попытался изменить различные Invoke's для BeginInvoke.

Резюмируя мне нужен ответ на один из этих двух вопросов:

1. Что ставит мой UI нить в режим ожидания таким образом, что Invoke висит?
2. Существует ли лучший класс ObservableCollection для использования?
   • this seems so over the top

Спасибо за раздумье.

UPDATE

Ну, я не знаю, нужно ли удалять этот вопрос и начать заново или что. Похоже, что проблема связана с ListCollectionView, который я использовал для фильтрации ReportEntry. Мой FileViewModel имеет

public ListCollectionView FilteredReports {get; private set;} 

инициализирован следующим образом:

FilteredReports = new ListCollectionView(Reports); 
FilteredReports.Filter = FilterFunction; 

Когда я удалить FilteredReports, нет более повешение. Раздражающе, DataGrid Я использую это представление, поскольку ItemSource for находится в DataTemplate, поэтому перемещение фильтра на мое представление также нетривиально. Итак, любая причина, по которой ListCollectionView висит на обновлениях коллекции?

Answer 1

Вместо ответа позвольте мне спросить. В сценарии «зависания приложений» вы попытались отключить опцию «Исключить исключение CLR» в отладчике?

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

Я прошу об этом, потому что в очень редких сценариях я видел тупики глубоко внутри внутренних элементов WPF, когда возникает неожиданное исключение (я считал их Mandelbugs). И исправление этого исключения также устраняет проблему взаимоблокировки.

Answer 2

Убедитесь, что ваш собственный объект ListCollectionView не создается в фоновом потоке. У меня была такая же проблема, и я нашел этот совет по телефону http://social.msdn.microsoft.com/Forums/en/wpf/thread/410a0b39-dfdb-4115-8a68-4ccabc17bcb6. Я действительно делал это и убедился, что ListCollectionView был построен на потоке пользовательского интерфейса, и решил мою «зависающую» проблему.