Бесконечный цикл, аннулирующий TimeManager - программирование
Подтвердить что ты не робот

Бесконечный цикл, аннулирующий TimeManager

У меня очень сложный дефект в моем приложении WPF для отслеживания. Сообщение об ошибке:

Бесконечный цикл, как представляется, вызван неоднократно аннулирование TimeManager во время процесса Layout/Render.

Трассировка стека (для чего она стоит):

в System.Windows.Media.MediaContext.RenderMessageHandlerCore(объект resizedCompositionTarget) в System.Windows.Media.MediaContext.RenderMessageHandler(Объект resizedCompositionTarget) в System.Windows.Threading.ExceptionWrapper.InternalRealCall(Делегат callback, Object args, Int32 numArgs) в MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen(Объект источник, метод делегирования, объектные аргументы, int32 numArgs, делегат catchHandler)

Это прерывистый дефект, и единственное место, где я когда-либо мог его поймать, - это файл конфигурации приложения, в котором я захватываю сообщение Application_DispatcherUnhandledException. Все, что у меня есть в моем приложении, завернуто в блоки захвата попытки, и все же это завершается в месте, где можно поймать необработанные исключения.

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

4b9b3361

Ответ 1

Ожидается, что вы не сможете поймать исключение в коде: ваша ошибка исходит из части Xaml вашего приложения, скорее всего, из анимации.

Итак, если вы создаете анимацию в Xaml или используете код, вы, например, запускаете анимацию A для начала, когда анимация B останавливается, и анимация B останавливается при запуске анимации A. Итак, у вас бесконечный цикл: A Пуск → B останавливается → A Пуск → B остановка → ...

На самом деле существует множество бесконечных сценариев цикла. Они могут быть вызваны обработчиком CurrentStateInvalidated ИЛИ обработчиком Completed, или CurrentTimeInvalidated, и я могу забыть некоторые сценарии, используя другие типы триггеров (мышь,...) и/или три ранее упомянутых. Возможно, код слишком сложный.

Удалите все анимации, чтобы протестировать этот сценарий.

Попробуйте иметь четкий способ воспроизвести ошибку и проверить, какие обработчики могут быть задействованы в таком цикле и бесконечно называть себя друг другом.

... вы также можете использовать счетчик в обработчиках и, например, checkBox предупредит вас, что было достигнуто заданное (большое) количество вызовов. Этот checkBox также даст имя обработчика. нажмите "ОК" несколько раз, чтобы проверить "члены" цикла.
Вы можете сохранить аналогичный код в версии выпуска и записать файл журнала только один раз, когда это число будет достигнуто, тогда обработчик всегда вернется, прежде чем что-либо предпринять. Лучше, чем крушение.

... или просто просмотр кода может показать вам возможный цикл (ы).

Надеюсь, что это поможет.

ИЗМЕНИТЬ: пожалуйста, послушайте мой совет:

A) удалите все анимации, протестируйте приложение и посмотрите, что произойдет. B) Если вы больше не видите ошибку: это причина.

C) Затем в анимах попробуйте удалить самый "опасный" триггер, триггер события. Вы можете поместить XAML в комментарии, используя, так что просто скопируйте за триггер  после анимации.

D) Повторите тест: если вы больше не видите ошибку, это триггер события E) Просмотрите все триггер событий и посмотрите на цикл, подобный описанному выше.

если в D), вы все еще видите ошибку, повторяете в C) с другими триггерами (Trigger Trigger/Data Trigger)


Во-вторых, хотя это может быть триггер свойств/данных с некоторыми изменениями данных очень часто...


Поместите некоторые xaml, возможно.


У меня возникла идея: постарайтесь установить контрольную точку в своем приложении Application_DispatcherUnhandledException. Затем наблюдайте внутреннее исключение внутреннего исключения... пока не достигнете MS.Internal.Threading.ExceptionFilterHelper.TryCatchWhen. исключение, то вы можете узнать источник. я не удивлюсь, что это сетка Infragistics, вызывающая проблему. Я когда-то тестировал контроль Telerik, и после борьбы с несколькими ужасными проблемами я просто вернулся к классической сетке, которую я настраивал сам: деньги и время были сохранены. Я быстро наблюдал за этой сеткой: они похожи на ваши проблемы с конвертерами или пользовательскими стилями с этой сеткой. - > попробуйте, если возможно, стандартный DataGrid.
- > Если нет ошибки, у нас есть первопричина: попробуйте "голую" Infragistic grid, затем проверьте, затем добавьте стиль, затем проверьте. Я не уверен, что вы можете протестировать без конвертеров. Тем не менее всегда возможно, чтобы модель представления отображала "преобразованные" свойства...

Снова: в своем сообщении процитируйте свой xaml, опишите неудачные случаи.

Ответ 2

Временами исключения очень сложны. Одно из предложений состоит в том, чтобы иметь блок catch без объекта исключения. Таким образом, вы можете обновить свой блок catch:

 catch(Exception ex)
{
..
}

к

    catch()
{
..
}

Существуют и другие исключения низкого уровня, которые трудно поймать, как указано в ответе Peli