Поиск:

Ответ в темуСоздание новой темы Создание опроса
> Как лучше организовать отслеживание живых форм? С разделением форм на классы. 
:(
    Опции темы
ZVano
Дата 18.4.2011, 15:16 (ссылка) | (нет голосов) Загрузка ... Загрузка ... Быстрая цитата Цитата


Опытный
**


Профиль
Группа: Участник
Сообщений: 259
Регистрация: 11.12.2006
Где: Украина, Кривой Р ог

Репутация: 1
Всего: 4



Топик создан в связи с отклонением от темы тут.
Давайте обсудим как лучше организовать программу-оболочку, чтобы ядро знало какие формы определенных классов живы.

Варианты:
1. Каждая форма определенного класса при создании должна помещать себя в список форм, а при уничтожении убирать себя из этого списка.
Код

// В ядре заводим глобалную переменную "список форм"
set<TForm*> active_forms;
set<TForm*> active_forms_class2;
//...


// В конструкторы всех форм, которые используются в приложении (и нуждаются в помещении в список), добавляем  следующую строчку
active_rorms.insert(this);

// А в деструктор - такую строчку
active_forms.erase(this);


// Везде, где нужно проверить жива ли форма пищем следующее:
// Проверка валидности формы -
if (active_forms.count(<form ptr>)!=0) ... // Валидна


Достоинства: 
* максимальное быстродействие; 
* при правильном использовании гарантируется достоверность информации.
Недостатки: 
* необходимо в конструктор\деструктор всех форм вставлять строчки добавления\удаления указателей форм в "active_forms".
* информация недостоверна, если программист забыл добавить строчки в конструктор\деструктор.

2. Подход 1 с той разницей, что программистом создается форма-шаблон, от которой наследуются все остальные формы.
Достоинства: те же, что у подхода 1.
Недостатки: ?Вроде, нет?

3. Мониторинг форм.
По таймеру мониторить все формы, по косвенным признакам определять класс.
На основе полученой информации обновлять списки указателей на формы.

Достоинства: 
* при создании форм не нужно следовать определенной схеме (как в методе 1)
* метод не зависит от ошибок программистов (как в методе 1)
* форма не обязана быть наследником от какого-то класса (как в методе 2). В класс предка можно поместить что-то более полезное.
* метод гарантирует достоверность информации на момент последнего сканирования (при условии, что эту информацию можно получить)

Недостатки: 
* информация достоверна на момент последнего сканирования.
* расход ресурсов на постоянный мониторинг
* способ неработоспособен, если форма не имеет признаков, по которым можно определить ее класс.


--------------------
НЕ ФЛУДИМ. Пользуемся кнопками "+" или "-" для выражения своего отношения к теме или сообщению.
Гуглим "Как правильно задавать вопросы"
PM MAIL Skype   Вверх
  
Ответ в темуСоздание новой темы Создание опроса
Правила форума "С++ Builder"
Rrader

Запрещается!

1. Публиковать ссылки на вскрытые компоненты

2. Обсуждать взлом компонентов и делиться вскрытыми компонентами

  • Литературу по С++ Builder обсуждаем здесь
  • Действия модераторов можно обсудить здесь
  • С просьбами о написании курсовой, реферата и т.п. обращаться сюда
  • Настоятельно рекомендуем заглянуть в DRKB (Delphi Russian Knowledge Base) - крупнейший в рунете сборник материалов по Дельфи


Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, Rrader.

 
0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей)
0 Пользователей:
« Предыдущая тема | C++ Builder | Следующая тема »


 




[ Время генерации скрипта: 0.0443 ]   [ Использовано запросов: 22 ]   [ GZIP включён ]


Реклама на сайте     Информационное спонсорство

 
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности     Powered by Invision Power Board(R) 1.3 © 2003  IPS, Inc.