Существуют ли проблемы с точками останова DTN_DATETIMECHANGE и элементом управления выбора времени?
У меня есть приложение для Windows, над которым я работаю, и возникла странная проблема при отладке. Я использую WTL, и у меня есть CDateTimePickerCtl в форме, чтобы установить дату. Я обрабатываю событие DTN_DATETIMECHANGE со следующим в моей карте сообщений:
NOTIFY_HANDLER(CONTROL_ID_DATE, DTN_DATETIMECHANGE, OnDateChanged)
Это прекрасно работает, когда приложение работает в отладчике без точек останова. Если у меня есть точка останова в функции OnDateChanged, даже в первой строке, VS зависает, если я меняю время с помощью выпадающего календаря. Нет проблем, если я отредактирую дату, введя в элемент управления.
Я даже пытался заставить OnDateChanged просто вызвать PostMessage с сообщением для конкретного приложения, чтобы попытаться обойти проблему, но если у меня есть точка останова в этом обработчике сообщений, я получаю ту же странную проблему.
Это становится еще более странным. Мало того, что VS зависает, но после зависания VS, некоторые другие приложения также будут зависать. IE 10, Chrome, Outlook зависают, Блокнот нет. Это полностью повторяется.
Мне приходится несколько раз убивать VS через диспетчер задач.
Вы можете увидеть билет, который я открыл с MS Connect здесь:
Главный вопрос, который у меня есть, заключается в том, видел ли кто-либо еще эту проблему и / или может ли она ее воспроизвести. У меня был другой разработчик, который репродуцировал на другом компьютере с тем же кодом, но я не собрал урезанную версию кода, чтобы просто репо.
Также обратите внимание, что я использую VS 2008 на 64-битной Win7.
Решение
В более ранних версиях Windows у меня была такая же проблема со списками. Особенно, когда точка останова устанавливается в закрытое время и инициируется другой активацией управления или около того. Очень похоже, что проблема существует и в datetime. Для таких случаев я бы рекомендовал использовать вызов TRACE / ATLTRACE для целей отладки.
Другие решения
Этот вопрос довольно старый, но, возможно, этот ответ поможет кому-то наткнуться на это:
На веб-сайте Microsoft Connect возникла проблема (https://connect.microsoft.com/VisualStudio/feedback/details/490277/, ссылка больше не работает) описывает это поведение в среде C # / .NET.
Команда Microsoft выяснила, что это было вызвано самим элементом управления Win32 DateTimePicker, который устанавливает глобальный хук мыши, вызывая описанное поведение.
Поскольку ошибка (?) Уже есть в Win32, она одинакова для приложений .NET / C ++.
Я не думаю, что ошибка будет исправлена. Ссылка на сайте Connect не работает.
Текущее решение состоит в том, чтобы не иметь точки останова в обработчике события DateTimePicker.