На главной форме лежит CTabCtrl, в него естественно в ран тайме добавляется несколько диалогов, достук к компонентам я могу получить (считать содежимое или записать туда), а вот как быть с кнопками, которые лежат на диалоге(одного из диалога дочерних окон)?

Т.е. если создать для етого окна свой класс то работает, а если создать обработку в классе "главного" окна, то обработка нажатия кнопки не вызывается

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

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

Вот именно, что мне надо делать во владельце
Есть на то причины

Ну дык переопредели PreTranslateMessage в каждом дочернем диалоге и возвращай FALSE в любом случае (так сообщение не будет обработано, а будет передано в родительское окно), или там-же посылай PostMessage-ой такое же сообщение с такими же параметрами в родительское окно. А в нём (т.е. в главной форме) обработай.

Или храни обратный указатель на родителя и вызывай его функции

Согласен с DENNN.

Цитата

так сообщение не будет обработано, а будет передано в родительское окно

mr.DUDA, а ты уверен. Я так понимаю, что кнопа пошлёт сообщение непосредственно диалогу и никому больше, даже если диалог откажется его обработать. Или я ошибаюсь?

Цитата

На главной форме лежит CTabCtrl, в него естественно в ран тайме добавляется несколько диалогов

А можно уточнить, что на форме лежит ? Может это CPropertySheet, в который можно добавлять диалоги ? В противном случае, я не догоняю, как можно что-либо "добавить" в CTabCtrl...

Цитата

кнопа пошлёт сообщение непосредственно диалогу и никому больше, даже если диалог откажется его обработать

Вообще, сообщение гуляет по окнам пока не дойдет до главного окна приложения, либо пока его не достанут из очереди (PeekMessage). Если вернуть в PreTranslateMessage значение FALSE, либо вообще не обрабатывать клик на кнопке внутри дочернего диалога, сообщение пойдет по инстанциям... и так или иначе придет к главному окну...

Цитата

Вообще, сообщение гуляет по окнам пока не дойдет до главного окна приложения

Хм... Сейчас посмотрим. Как я понимал, сообщения бывают двух типов. Те, что проходят через очередь сообщений и посылаются окну функцией DispatchMessage, и те, что посылаются непосредственно окну из любого места программы, минуя очередь, функцией SendMessage. Так вот, по-моему, мы говорим о сообщении первого типа. Но ведь функция DispatchMessage вызовет оконную процедуру именно диалога (именно его дескриптор прописан в поле hwnd структуры MSG). Короче, сейчас посмотрим. Я собираюсь создать окно, разместить на нём диалог с кнопой и ждать сообщения от кнопки в главном окне.

Слушай, mr.DUDA. Если создать немодальный диалог на обычном окне. То сообщения от кнопок на этом диалоге не посылаются в обычное окно ни при каких обстоятельствах. Может в MFC какой-то специальные механизм проработан, например, свой аналог Dispatch'а, но в API такое не катит.
P.S. Вообще, я тут подумал: посмеются над нами знающие люди .

Цитата

Если создать немодальный диалог на обычном окне. То сообщения от кнопок на этом диалоге не посылаются в обычное окно ни при каких обстоятельствах

Разберёмся подробнее, что происходит при нажатии кнопки. Как говорит MSDN, при нажатии кнопки генерится сообщение WM_COMMAND, которое посылается окну-хозяину кнопки. Замечательно. Если оно не будет обработано, то по идее д.б. передано в родительское окно. Попандос номер 1: "нифига",- сказали авторы MFC :

Код

///////////////////////////////////////////////////////////////////////////// // main WindowProc implementation LRESULT CWnd::WindowProc(UINT message, WPARAM wParam, LPARAM lParam) {       // OnWndMsg does most of the work, except for DefWindowProc call       LRESULT lResult = 0;       if (!OnWndMsg(message, wParam, lParam, &lResult))              lResult = DefWindowProc(message, wParam, lParam);       return lResult; } BOOL CWnd::OnWndMsg(UINT message, WPARAM wParam, LPARAM lParam, LRESULT* pResult) {       LRESULT lResult = 0;       // special case for commands     <--------------- !!!!!!!!!!!!!!!!!!!!!!!!!!!!       if (message == WM_COMMAND)       {              if (OnCommand(wParam, lParam))              {                     lResult = 1;                     goto LReturnTrue;              }              return FALSE; // <---------  ???   Просто выход  ???       }       // special case for notifies       if (message == WM_NOTIFY)       {       ...

А вот и причина попандоса. Если сообщение WM_COMMAND не обрабатывается окном, то оно вообще никуда больше не посылается. Эге...

Что же делать ? А то, что определить в дочернем диалоге функцию OnCommand, в которую написать:

Код

BOOL CMyChildDialog::OnCommand(WPARAM wParam, LPARAM lParam) {       return GetParent()->SendMessage(WM_COMMAND, wParam, lParam); }

Главное, что данный метод работает !

Теперь останется только определить в родительском окне (в форме, диалог, или что там у hunter_eea'а)обработчики нажатия на кнопку, сделав это вручную конечно же (кнопка-то там не существует). Как это сделать ?

Гы, очень просто:
1) создаём ClassWizard'ом обработчик кнопки в том (дочернем) диалоге где кнопка лежит
2) выдираем весь появившийся код из этого (дочернего) диалога и вставляем в родительский диалог. Не забываем изменить имена классов.

ЗЫ:

Цитата

Вообще, я тут подумал: посмеются над нами знающие люди

Не думаю, что кому-то охота будет посмеяться... Хотя, некоторые могут...

Цитата

Разберёмся подробнее, что происходит при нажатии кнопки. Как говорит MSDN, при нажатии кнопки генерится сообщение WM_COMMAND, которое посылается окну-хозяину кнопки. Замечательно. Если оно не будет обработано, то по идее д.б. передано в родительское окно. Попандос номер 1: "нифига",- сказали авторы MFC

Ну, не прав ты! Не должно оно ни по идее, ни без идеи передаваться родительскому окну. У Windows другие принципы. И это не решение MFC, а операционной системы в целом.
Твоё решение задачи имеет право на существование, но по-моему не самое лучшее. Возвращаясь к принципам ОС: ID каждого control'а должен быть уникален в пределах окна владельца, а не приложения в целом. Поэтому возможно, что этот ID в главном окне будет принадлежать другому ресурсу. Я против такого решения. На мой взгляд, лучше определить своё сообщение вместо WM_COMMAND, а еще лучше вызывать нужный метод прям из proc'а диалога. Ведь вспомни, что hunter_eea хотел изначально. Он хотел обойтись одним CDialog. Ответ - это невозможно, если надо реагировать на события, происходящие в диалоге.

Цитата

Ответ - это невозможно, если надо реагировать на события, происходящие в диалоге.

Согласен

Насчет

Цитата

Не должно оно ни по идее, ни без идеи передаваться родительскому окну

не согласен. Набираем "command routing" в индексе MSDN (раздел относится к VisualC++) и читаем.

Цитата

Windows messages are usually sent to the main frame window, but command messages are then routed to other objects. The framework routes commands through a standard sequence of command-target objects, one of which is expected to have a handler for the command. Each command-target object checks its message map to see if it can handle the incoming message.

и дальше

Цитата

The general order in which a command target routes a command is: To its currently active child command-target object. To itself. To other command targets.

Потом идет перечисление последовательности, по которой передаются сообщения для разных типов объектов.

Я еще раньше где-то читал о том, что любое оконное сообщение передается в родительское окно, если оно не было обработано в данном окне.

mr.DUDA, это о чём то другом. У меня нет MSDN, а on-line запрос повис. Но мне кажется, это не про WM_COMMAND, а про что-то другое.

По-поводу лабиринтов сообщений MFC на rsdn.ru была хорошая статья.