Предыстория: в настоящее время я отлаживаю приложение, написанное на основе пользовательского графического интерфейса пользователя на C++. Мне удалось выявить большинство ошибок, но ошибки, с которыми у меня больше всего проблем, обычно имеют общую тему. Все они, похоже, связаны с обновлением экрана, перерисовкой или обновлением для соответствия предоставленным данным. Это сложная задача для отладки, потому что я не могу прерывать каждое обновление, и большая часть этого материала зависит от времени, поэтому точки останова иногда «исправляют» ошибку.
В: Есть ли у кого-нибудь советы по отладке графических интерфейсов на базе Windows, особенно по обновлению отдельных компонентов?





Это может и не помочь, но я обнаружил, что в этом сценарии полезно использовать два монитора. У меня отладчик на одном экране, а приложение на другом. Затем я могу пройти через код и увидеть, как приложение обновляется или выполняет все, что находится на другом экране. По-прежнему есть проблемы с фокусировкой таким образом, но, по крайней мере, я могу видеть, когда он перекрашивается.
Наличие двойного экрана действительно помогает при отладке проблемы обновления / перерисовки элементов управления и пользовательского интерфейса Windows.
При наличии приложения на втором экране отладчик не будет генерировать «недействительный» на основных экранах пользовательского интерфейса, когда он прерывается для точки останова отладки.
Если у вас нет второго экрана, попробуйте расположить оба приложения рядом, чтобы приложение и отладчик не мешали.
Я согласен с двумя мониторами или даже с удаленной отладкой, чтобы уменьшить влияние на сообщения.
Я также очень рекомендую утилиты Spy. Они позволяют вам видеть, какие сообщения отправляются в систему. Одна из таких программ - Winspector. http://www.windows-spy.com/
Ведение журнала - практически единственный ответ. Не зная вашего фреймворка, я не могу дать точный ответ, но в основном открываю файл и добавляю сообщения в различные интересующие вас процедуры. Наконец закройте его.
В сообщении укажите значения интересующей вас переменной.
Также полезно использовать окно Message Box, чтобы увидеть, находитесь ли вы в правильной ветви или процедуре. Это имеет минимальное влияние на общий поток.
Наконец, попробуйте загрузить любую экспресс-версию .NET и использовать Winforms, чтобы попытаться протестировать особенно проблемные области. Несмотря на то, что Winform является собственной структурой, существует высокая степень соответствия между ее контролем и теми, которые предоставляет Windows.
Я поддерживаю симуляцию Project Mercury Capsule в качестве дополнения к Orbiter Space Simulator. Он написан на C++ и должен использовать Win32 непосредственно для некоторых панелей и диалогов. Были времена, когда я запускал VB6 (позже VB.NET), чтобы проработать какое-то сложное взаимодействие, а затем переводил его на эквивалент Win32 на C++.
Однако это последнее средство.
Ссылка битая, перенаправлена на какой-то сомнительный сайт фотосессии.