Справочник функций

Ваш аккаунт

Войти через: 
Забыли пароль?
Регистрация
Информацию о новых материалах можно получать и без регистрации:

Почтовая рассылка

Подписчиков: -1
Последний выпуск: 19.06.2015

Сообщения пользователя

3.6K
20 июля 2003 года
void_123
11 / / 30.06.2003
Предлагаю дискуссию.
Как организовать обмен пользовательскими «сообщениями»между классами приложения MFC, которые бы отражали общую бизнес-логику программы?
Вопрос не в том, как это вообще можно сделать, а как сделать эффективнее, с точки зрения скорости разработки приложения VC++.

Хотя вопрос касается приложений MFC, но для лучшего его понимания - начну со стиля построения приложений, который я уже лет 6 использую в BC++ Builder.
Удобно для оконной формы BC++ Builder с большим числом контролов (50-100, что характерно для приложений баз данных) определить две функции, например,bool FillControls(unsigned int msg) и bool DisplayControls(unsigned int msg) для обработки «сообщений» пользователя типа CLEAR_CONTROLS, READ_DATABASE, SAVE_DATABASE и т.д:
bool FillControls(unsigned int msg)
{
switch( msg )
{
case STARTUP: …..
case CLEAR_CONTROLS: …..
case READ_DATABASE: …..
}
}
Например, по нажатию кнопки «Открыть», обработчик кнопки делает последовательность вызовов FillControls(READ_DATABASE) и DisplayControls(READ_DATABASE). Это приводит к тому что, соединяемся с DB, читаем данные в контролы и перерисовываем их, контролируя на каждом шаге, что должно быть disable, что enable, что readonly и т.д.
Удобство заключается в том, что всё управление отображением и заполнением контролов (enable, visible и т.д) сосредоточено в одном месте. Вернее сосредоточена общая логика приложения в части управления контролами.
Такую обработку несложно построить в BC++, т.к. все контролы являются членами класса формы приложения. Т.е из указанных выше функций (методов формы) видны все контролы.
Гораздо сложнее это реализовать в VC++. Это связано с тем, что классы, в которых созданы члены-контролы ничего не знают друг о друге, и не видят соответствующих контролов в общем случае. Например, если Вы создали приложение с CTreeView – СFormView, где на форму положили CTabCtrl и для каждой закладки создали по диалогу CPage1,…., CPage20, то для каждого класса!!! придётся писать соответсвующие обработчики bool FillControls(unsigned int msg), bool DisplayControls. При этом необходимо ещё найти приемлемый механизм обмена сообщениями между классами.

У кого есть идеи? Предлагаю для затравки тупой метод решения задачи - использование глобальных указателей на каждый из диалогов. Умные – предложите Вы.

Делаем тупо:
extern CTvView* pTV;
extern CPage1* Page1;

extern CPage20* Page20;

bool FillControls(unsigned int msg)
{
switch( msg )
{
case STARTUP:
pTV->Clear();
Page1->ClearControls();
….
Page20->ClearControls();

}
}
3
20 июля 2003 года
Green
4.8K / / 20.01.2000
Цитата:
Originally posted by void_123
Предлагаю дискуссию.
Как организовать обмен пользовательскими «сообщениями»между классами приложения MFC, которые бы отражали общую бизнес-логику программы?
Вопрос не в том, как это вообще можно сделать, а как сделать эффективнее, с точки зрения скорости разработки приложения VC++.

Хотя вопрос касается приложений MFC, но для лучшего его понимания - начну со стиля построения приложений, который я уже лет 6 использую в BC++ Builder.
Удобно для оконной формы BC++ Builder с большим числом контролов (50-100, что характерно для приложений баз данных) определить две функции, например,bool FillControls(unsigned int msg) и bool DisplayControls(unsigned int msg) для обработки «сообщений» пользователя типа CLEAR_CONTROLS, READ_DATABASE, SAVE_DATABASE и т.д:
bool FillControls(unsigned int msg)
{
switch( msg )
{
case STARTUP: …..
case CLEAR_CONTROLS: …..
case READ_DATABASE: …..
}
}
Например, по нажатию кнопки «Открыть», обработчик кнопки делает последовательность вызовов FillControls(READ_DATABASE) и DisplayControls(READ_DATABASE). Это приводит к тому что, соединяемся с DB, читаем данные в контролы и перерисовываем их, контролируя на каждом шаге, что должно быть disable, что enable, что readonly и т.д.
Удобство заключается в том, что всё управление отображением и заполнением контролов (enable, visible и т.д) сосредоточено в одном месте. Вернее сосредоточена общая логика приложения в части управления контролами.
Такую обработку несложно построить в BC++, т.к. все контролы являются членами класса формы приложения. Т.е из указанных выше функций (методов формы) видны все контролы.
Гораздо сложнее это реализовать в VC++. Это связано с тем, что классы, в которых созданы члены-контролы ничего не знают друг о друге, и не видят соответствующих контролов в общем случае. Например, если Вы создали приложение с CTreeView – СFormView, где на форму положили CTabCtrl и для каждой закладки создали по диалогу CPage1,…., CPage20, то для каждого класса!!! придётся писать соответсвующие обработчики bool FillControls(unsigned int msg), bool DisplayControls. При этом необходимо ещё найти приемлемый механизм обмена сообщениями между классами.

У кого есть идеи? Предлагаю для затравки тупой метод решения задачи - использование глобальных указателей на каждый из диалогов. Умные – предложите Вы.

Делаем тупо:
extern CTvView* pTV;
extern CPage1* Page1;

extern CPage20* Page20;

bool FillControls(unsigned int msg)
{
switch( msg )
{
case STARTUP:
pTV->Clear();
Page1->ClearControls();
….
Page20->ClearControls();

}
}



Если правильно понял, то тема касается архитектуры приложения, OOD&A. Рекомендую ознакомиться с теорией паттернов. В данном случае подойдет паттерн "Mediator" ("Посредник"). Информации по паттернам много и в интернете и в печатных изданиях. Вот очень наглядная ссылка, можно использовать, как справочник:
http://ooad.asf.ru/patterns/
В частности, паттерн "Посредник":
http://ooad.asf.ru/patterns/patterninfo.asp?id=23

3.6K
22 июля 2003 года
void_123
11 / / 30.06.2003
Да, Зелёный. Вы всё правильно поняли.
Посмотрел ссылки. Спасибо. Весьма интересно.
Почти то же и я хочу, но проще.
Реклама на сайте | Обмен ссылками | Ссылки | Экспорт (RSS) | Контакты
Добавить статью | Добавить исходник | Добавить хостинг-провайдера | Добавить сайт в каталог