событие потери указателя (переполнение очереди?) - PullRequest
Новая
       5

событие потери указателя (переполнение очереди?)

0 голосов
/ 31 января 2019

Я написал приложение WUP на C ++ (MS Developer Studio 2017, нацеленное на 10.0.17134.0).В основном это эмулятор музыкальных инструментов, реагирующий на события PointerEntered и PointerExited, отправляющий штрихи в слой Midi.Пока все работает нормально, но когда приложение загружено (то есть я играю быстрее или нажимаю несколько кнопок одновременно), я теряю события.Это отображается с помощью «липких» клавиш (нота продолжает звучать даже после отпускания v-кнопки (объекта границы, представляющего клавишу)).Так как я также изменяю цвет v-кнопки с введенным указателем (цвет включен) и с указателем выход (цвет выключен), я вижу, что обработчик событий не вызывается, и это не проблема на слое Midi (цвет остаетсякак кнопка v отпущена).У меня есть основания полагать, что это относится не только к событиям PointerExited, но и к событиям PointerEntered (часто заметка не звучит, даже если я четко касаюсь соответствующей V-кнопки).

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

Спасибо!

Редактировать 01.02.2009: Я немного оптимизировал код, и проблема больше не проявляется.Для тех, кто заинтересован, вот псевдокод, вызвавший проблему: 

HandlerForPointer()
{
    IMidiMessage ^a_Msg = ref new <a midi message>;
    member_midiport->SendMessage(a_Msg);
}

Сделав сообщение переменной-членом экземпляра класса и инициализируя его один раз вместо того, чтобы каждый раз заново генерировать новое сообщение, как это: 

HandlerForPointer()
{
    member_midiport->SendMessage(member_message);
}

Мне удалось устранить проблему (насколько я могу судить до сих пор; регрессивные тесты еще не завершены).Это будет означать, что воссоздание сообщения (либо новое, либо вызов конструктора), либо неявное удаление ссылки в конце области занимает столько времени ЦП, что поток пользовательского интерфейса вызывает переполнение очереди сообщений.Надлежащим способом проверки этого было бы введение меток времени и, таким образом, измерение истекшего времени для определения максимального времени выполнения в любом случае.Возможно, этот счетчик производительности может быть правильной точкой входа для этих измерений: doc link .

Извините за шум и спасибо за ответ.

...