CallWindowProc для диалогов? Как можно заменить процедуру диалога?

в рантайме - как и для всех остальных окон, через SetWindowLong и GWL_WNDPROC

а вот кгда ты сам управляешь ресурсом, то можно диалог просто наследовать (суперклассить)
для этого нужно: зарегистрировать класс-потомок от диалога, а в ресурсах самого диалога заполнить свойство "Class"
тут нужно указать имя этого зарегистрированного класса

в программе все аналогично, как с обычным диалогом, за исключением последнего параметра (lpDialogFunc),
в него можно передать NULL:


Добавлено через 1 минуту и 39 секунд
да, вместо DefWindowProc, в перекрытой процедуре окна нужно уже вызывать DefDlgProc 

Я создаю главное окно через CreateDialog. Использовать DefWindowProc или DefDlgProc?

Добавлено через 1 минуту и 14 секунд
Чета у меня не получается CreateDialog и DefWindowProc в класс завернуть...

без разницы, какой функцией создавать диалог,
при перекрытии, в любом случае нужно уже вызывать DefDlgProc,
напоминаю условия суперклассинга диалогов: http://msdn.microsoft.com/en-us/library/ms...px#custom_boxes

Для начала, сдесь все правильно?


Это сообщение отредактировал(а) Alca - 19.6.2009, 11:18

нет,
поправка 1:

поправка 2:

сколько раз повторять, не используйте условную посылку системных функций типа DefWindowProc, это источник массы неявных ошибок
поправка 3:

неудивительно, тут же рекурсия

а в остальном, как я понимаю, раз идет рекурсия, значит свойство Class выставлено правильно, т.е. в TestWindowClass
после поправок 1 и 3, все должно работать

::DefDlgProc действительно был лишний и 
если диалог создается с ресурсов, то:

GremlinProg, спасибо! Буду дальше разбираться.

Добавлено через 9 минут и 3 секунды
Хочу вступить в клуб волшебников!!!!   

нет, Alca, ты не понял
DefDlgProc тут не лишний,
просто, когда в последний параметр CreateDialog ты ставишь lpMainProc,
то, тем самым, из lpMainProc делаешь обычную диалоговую процедуру (при этом, обычно компилятор ругается на несоответствие типов, там у колбэков типы обратных результатов разные),
а раз эта процедура является и процедурой окна,
то DefDlgProc, на всякий нулевой возврат из контекста диалоговой функции, будет вызывать его вновь и вновь, т.е. зациклится
можешь это проверить простым статическим счетчиком на любом единичном сообщении, типа WM_LBUTTONDOWN или WM_SHOWWINDOW

а про default, я все подробно объяснил тут: http://forum.vingrad.ru/forum/topic-260881...size/index.html
неочевидно, но, как видишь, есть очевидные прецеденты

Так а чего туда писать надо?

Добавлено через 43 секунды

Видел WINPROC и DLGPROC.

Добавлено через 2 минуты и 59 секунд
Я просто убрал:

NULL

это означает лишь то, что диалоговая процедура не будет вызвана, но и стандартный DefWindowProc - тоже

поясняю: из DefDlgProc вызывается DefWindowProc, это цепочка наследования диалога, а когда ты не вызываешь DefDlgProc, ты обрываешь эту цепочку, окно перестает нормально работать, т.е. лишается всего функционала, который давали ей эти процедуры

Так что ли? А как я буду обрабатывать сообщния? 


Это сообщение отредактировал(а) Alca - 19.6.2009, 15:45

да, именно так


сообщения здесь обрабатывает уже процедура окна класса TestWindowClass

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

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

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

понимаешь разницу между этими двумя процедурами?

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