Delphi 6: установите контрольные точки включил основные перекрашивания потока остановок потока не-VCL
У меня есть многопоточное приложение Delphi 6 Pro, что я в настоящее время продолжаю работать в большой степени. Если я установил точку останова на каком-либо коде, который работает в контексте Основного потока (поток VCL), у меня нет проблем. Однако, если точка останова инициирована на каком-либо коде в одном из моих других потоков, после того, как я продолжаю приложение от точки останова, всех перекрашиваний к компонентам VCL на основном потоке (включая основную форму) больше не происходит. Приложение не мертво, потому что другой фоновый код продолжает бежать, просто основной поток. Это - как будто окна обмениваются сообщениями, диспетчер был поврежден или представлен бездействующий.
Отметьте в этом приложении, я выделяю свой собственный WndProc () через allocateHwnd () на основной форме, потому что я должен поймать определенные зарегистрированные сообщения. От того, что WndProc () я диспетчеризирую любые пользовательские сообщения, которые я обрабатываю и если текущее сообщение не обрабатывается моим кодом, я передаю сообщение путем вызова основной формы, наследовал WndProc (). Если я действительно обрабатываю текущее сообщение, я просто возвращаюсь из своего WndProc () с сообщением. Набор результатов к 1, чтобы сказать диспетчеру, что сообщение было обработано. Я не могу просто переопределить TForm WndProc () вместо того, чтобы выделить мой собственный WndProc (), потому что по некоторым причинам Delphi VCL не проходит через зарегистрированные сообщения, которые инстанцируют с Windows API RegisterWindowMessage () вызов.
Кто-либо испытал это в подобном контексте и если так, что Вы делали для фиксации его?
- roscherl
2 ответа
Поскольку вы вызываете AllocateHWnd, это означает, что вы создали еще одно окно. Вы не должны просто брать сообщения, которые были адресованы этому окну, и пересылать их в окно вашей формы. Делая это, вы обязательно что-то испортите в своей программе, хотя я не уверен, как именно. Проблемы с рисованием звучат правдоподобно. Вы должны убедиться, что это действительно только проблемы с рисованием, а не то, что ваш основной поток все еще приостановлен. Отладчик должен быть в состоянии сказать вам это. (Вам следует вызвать DefWindowProc, чтобы заставить ваше выделенное окно обрабатывать сообщения, которые вы не готовы обрабатывать самостоятельно. А возврат 1 ничего не говорит диспетчеру; диспетчеру это не важно - тот, кто вызвал SendMessage, хочет знать результат.)
Я обещаю вам, что формы вполне способны получать зарегистрированные оконные сообщения. Переопределите WndProc или присвойте новое значение свойству WindowProc (и не забудьте сохранить старое значение, чтобы вы могли вызвать его после обработки собственных сообщений). Источник вашей проблемы лежит в другом месте.
ОБНОВЛЕНИЕ: Я не говорю, что способ решения проблемы - хорошее решение. Мне нужно взять заметки Роба Кеннеди и провести рефакторинг. Однако, чтобы решить эту проблему, я дал потоку собственные Window и WndProc (), а в верхней части цикла Execute у меня есть цикл PeekMessage () while с вызовами TranslateMessage () и DispatchMessage (). У меня больше нет проблем с установкой точек останова в потоке, но очевидно, что такое сочетание методов WndProc () указывает на структурную проблему в моем коде. Я хотел добавить этот ответ, чтобы заполнить обсуждение. Я надеюсь, что как только я заставлю предложения Роба работать, когда я очищу свои методы WndProc () в соответствующих формах, особенно в основной форме, я смогу избавиться от этого нового WndProc (), который я только что добавил в поток.
Роберт.