Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
[C++] Дополнения к дополнению 22.07.03 09:53 Число просмотров: 1391
Автор: amirul <Serge> Статус: The Elderman
Отредактировано 22.07.03 10:01 Количество правок: 1
|
> > В VC++ (в частности в MFC Class Wizard-е - вызывается
> > клавишей Ctrl-W) можно добавлять переменные в
> сгенеренный
> > класс. В частности в класс диалога можно добавить
> > переменные TreeView-а и TabCtrl-а.
> Ты меня не понял. Нет проблем с созданием переменных.
Я собственно не о создании. Если какой-то элемент помещен на форму, то он будет создан при инициализации CDialog-а. Речь идет о добавлении переменных-указателей на эти самые элементы. Если все элементы не видны из одного диалога ничто не мешает добавить переменные для разных диалогов в CWinApp (вернее его наследника, который создается Class Wizard-ом). Насколько я понял сделать это из самого Class Wizard-а тоже не получится, так как диалоги создаются/уничтожаются опять таки в run-time, а design-time-е не известно, будет ли валидна данная переменная. Поэтому указатели на диалоги можно поместить в этого самого наследника от CWinApp вручную, и выставлять их по мере создания/удаления диалогов (так как конструкторы/деструкторы диалогов видят глобальный theApp, то оттуда лучше всего это и делать - кому как не им знать когда создаются/уничтожаются диалоги). Основной диалог приложения создается в InitInstance как локальная перменная и потому уничтожается при выходе из области видимости (из InitInstance).
Ну а с известными указателями на диалоги уже можно из любого диалога получить доступ к любому элементу каждого диалога. Причем добавлять переменные в ClassWizard нужно ПОМИМО добавления элемента в диалог. Добавляется не сам объект так сказать, а указатель на него для последующего доступа. Причем, можно выбирать каким элементам нужны такие переменные, а какие будут на автопилоте управляться собственными событиями.
> TreeVew создаётся в классе CTreeView. Диалог, содержащий
> CTabCtrl
> создаётся из другого вида, например, CFormView. Затем из
> CFormView создаются диалоги закладок CTabCtrl. Поэтому, при
> обработке перемещения по дереву я не могу вызвать методы
> диалогов (страниц таба), чтобы синхронизироватьсодержимое
> их контролов с селектом листа дерева.
> Не могу не в том смысле, что вобще не могу, а втом, что при
> стандартном
> подходе, без дополнительного манагера это можно сделать
> только коряво.
Вообще я имел в виду, что данным нужно давать всплывать только до того места, откуда они будут видны всем желающим их видеть. Но не дальше. Максимум, куда можно дать всплыть этим данным - в мемберы CWinApp-а. А сам CWinApp и так глобальный (собственно приложение запускается вызовом его конструктора). В этом глобальном CWinApp-е можно хранить указатели на все создаваемые диалоги. А в диалогах хранить указатели на необходимые элементы (например на CTabCtrl) и т.д. (из CTabCtrl-а можно получить все страницы с сохраненным lParam, если при этом озаботиться передачей в lParam указателя на CPage при создании - то проблем не будет).
Такая иерархия ИМХО, самая правильная. Но даже если будут отличия - выводить переменные в global scope нужно очень осторожно.
> > Это правильно что не видят. Потому, что программист
> должен
> > сам знать чего хочет
>
> Не обобщай. Посмотри на ссылку на концепцию паттернов в
> предыдущих постах в этом топике.
> Там есть про медиатор и обжект обзервер. Они как раз и
> делаются для того,
> чтобы всё знать об объектах.
Я не о знании. В конце концов нужно объявить что ты хочешь знать об объекте, создав обсервер. Тут то же. MFC Class Wizard не добавляет указателей в класс, если программист не попросит об этом явно. А создаются объекты (в частности контролы в диалогах) и без этого. Чтоб не засорять пространство имен, можно добавлять только те указатели, с которыми предполагается работать. Остальные будут на автопилоте выполянть те обработчики сообщений, которые им зададут.
> > Но есть и более эффективный вариант (и более
> правильный с
> > точки зрения ООП). С TreeView-ом разобрались, а для
> страниц
> > правильнее сделать общий базовый класс, с описанием
> всех
> > функций, необходимых для работы (скорее всего
> виртуальных,
> > но это зависит от конкретной задачи).
>
> Естественно класс написан.
Вот указатель на него то и передавать в lParam при InsertItem-е в CTabCtrl. Тогда взяв (GetItem()) любой итем можно будет точно знать, что как минимум на объект этого базового класса этот lParam указывает. А точный тип знать не обязательно, если в базовом классе хорошо задан интерфейс.
> >.... по CPP-овски. Вызов функции тоже можно считать
> сообщением,
>
> Я бы сказал по другому - вызов функции должно быть реакцией
> на сообщение
Ну не совсем. В курсе ООП в универе (давно это было, да и слушал в полуха) мы рассматривали этот вопрос. Не скажу точно, да и искать сейчас в лом, но сообщение это ЛЮБОЙ метод одного объекта сообщить другому о каком то событии. В общем случае это как раз вызов одним объектом мембер-функции другого. Ну а если диспетчерезацию сообщений берет на себя система, то тут и появляются функции типа "доставить такое то сообщение такому-то абоненту".
> > поэтому вместо FillControls(STARTUP) лучше делать
> прямой
> > вызов ClearControls()-ов.
>
> Да, вот здесь я согласен. Об этом я напишу дальше отдельным
> постом
|
|
|
подробно о проекте
Анализ криптографических сетевых...
