Легенда:
 новое сообщение
 закрытая нитка
 новое сообщение
 в закрытой нитке
 старое сообщение
|
- Напоминаю, что масса вопросов по функционированию форума снимается после прочтения его описания.
- Новичкам также крайне полезно ознакомиться с данным документом.
[C++] Дополнения к дополнению 25.07.03 04:09 Число просмотров: 1426
Автор: void <Grebnev Valery> Статус: Elderman
|
amirul,
Извини, что не ответил сразу. Думал... В сомнениях я теперь.
*************************************
>>Я собственно не о создании….. для разных диалогов в CWinApp (вернее его наследника, который создается Class Wizard-ом). Насколько я понял сделать это из самого Class Wizard-а тоже не получится, так как диалоги создаются/уничтожаются опять таки в run-time, а design-time-е не известно, будет ли валидна данная переменная. Поэтому указатели на диалоги можно поместить в этого самого наследника от CWinApp вручную, и выставлять их по мере создания/удаления диалогов (так как конструкторы/деструкторы диалогов видят глобальный theApp, то оттуда лучше всего это и делать - кому как не им знать когда создаются/уничтожаются диалоги). Основной диалог приложения создается в InitInstance как локальная перменная и потому уничтожается при выходе из области видимости (из InitInstance).
A:
Собственно я так и делаю. В «главном» диалоге формы в качестве членов – указатели на все 20 диалогов пейджей. Если честно, то я сразу не дотукал, что сообщение, или функцию «Read» можно передать только «главному» диалогу, с тем, чтобы он разослал его своим детям, диалогам пейджей. А те уж сами знают, что делать по «Read»
************************************
>Ну а с известными указателями на диалоги уже можно из любого диалога получить доступ к любому элементу каждого диалога. Причем добавлять переменные в ClassWizard нужно ПОМИМО добавления элемента в диалог. Добавляется не сам объект так сказать, а указатель на него для последующего доступа. Причем, можно выбирать каким элементам нужны такие переменные, а какие будут на автопилоте управляться собственными событиями.
A:
Ты прав, за одним исключением. Я не собираюсь «…из любого диалога получить доступ к любому элементу каждого диалога…». Тем более, что они не должны быть паблик (контролы). Этот изврат был в начале топика, для «затравки».
************************************
>>Вообще я имел в виду, что данным нужно давать всплывать только до того места, откуда они >>будут видны всем желающим их видеть. Но не дальше. Максимум, куда можно дать всплыть >>этим данным - в мемберы CWinApp-а….
A:
Может и в качестве членов CWinApp-а. Если они будут приват, то единственное, что можно, сделать – это сделать вызов CMyApp::Read(), а тот уже расскажет своему приватному добру последовательно:
bool CMyApp::Read()
{
pTreeView->Read();
pMainDialog->Read(); // Этот щас в цикле сделает вызов для диалогов пейжей
…
…
}
А может при криэйте этих объектов их добавлять в некий класс, для которого обеспечена глобальная видимость для всех заинтересованных окошек. Кстати интересно, а как сделать так, чтобы доступ к паблик методам такого класса имели-бы только его подписчики, т.е. те, кто уже зарегистрирован при создании (указатель на этот объект)?
**************************************
>> Но даже если будут отличия - выводить переменные в global scope нужно очень осторожно.
A:
Надеюсь, ты понимаешь, что я не собираюсь делать в global scope НЕПОСРЕДСТВЕННО указателей на CWnd-объекты интерфейса.
**************************************
>>… А точный тип знать не обязательно, если в базовом классе хорошо задан интерфейс.
A:
Согласен. Но балбесянство CtabCtrl MFC выводит, т.к. классу каждой пейжи надо объяснять в переопределённой функции интерфейса базового класса, как надо обрабатывать «ЕнаблеКонтролс». В BCB++ c таб-компонентом проще. Из облати его видимости можно получить доступ ко всем контролам на каждой закладке, т.е. обабатывать поведение контролов по «ЕнаблеКонтролс» в одном методе, а не в 20-и.
|
|
|
подробно о проекте
Анализ криптографических сетевых...
