Правильное построение программы в MFC Doc\View
Сделал SDI приложение Doc\View
окно разделил Сплиттером на две части
на левую часть нацепил CLeftView, а на левую CRightView.
Классы практически идентичные. Всередине классов есть CGridCtrl (типа ЛистВью продвинутый с CodeProject'а).
Есть менюшка, на которой кнопки редактрировать, добавить и т.д.
К примеру нажатие кнопки на левой панели отлавливаю через сообщения левой панели. Запускаю ДлгОкошко в котром что-то редактируется. Потом если надо в CGridCtrl делаю необходимые изменения.
То есть если мне надо редактировать данные из левой панели, то я отлавливаю мессадж через левую панель. Если надо с правой - то через правую.
А мне вот сейчас надо редактироват данные с левой панели, и исправить то чно находиться в правой. Но я имею доступ только до одной панели одновременно. Вот как решить трабл?
P.S. Думаю все эти проблемы из-за неправильной структуры программы.
окно разделил Сплиттером на две части
на левую часть нацепил CLeftView, а на левую CRightView.
Классы практически идентичные. Всередине классов есть CGridCtrl (типа ЛистВью продвинутый с CodeProject'а).
Есть менюшка, на которой кнопки редактрировать, добавить и т.д.
К примеру нажатие кнопки на левой панели отлавливаю через сообщения левой панели. Запускаю ДлгОкошко в котром что-то редактируется. Потом если надо в CGridCtrl делаю необходимые изменения.
То есть если мне надо редактировать данные из левой панели, то я отлавливаю мессадж через левую панель. Если надо с правой - то через правую.
А мне вот сейчас надо редактироват данные с левой панели, и исправить то чно находиться в правой. Но я имею доступ только до одной панели одновременно. Вот как решить трабл?
P.S. Думаю все эти проблемы из-за неправильной структуры программы.
Нада манагер окон писать. ИМХО я б так сделал.
Цитата:
Originally posted by Alexandoros
Нада манагер окон писать. ИМХО я б так сделал.
Нада манагер окон писать. ИМХО я б так сделал.
Можно чуть подробней про идею менеджера окон?
Собственно это был бы не манагер окон, а , скорее манагер бизнес-логики программы (не знаю как назвать это по другому:) ). Типа События от одного контрола передаются манагеру, а он, соответсвенно их обрабатывает, и изменяет нужные значения других контролов. Естественно даный манагер "знает" обо всех контролах в пределах его подчинения.
Где-то так.
Где-то так.
Цитата:
Originally posted by Alexandoros
Собственно это был бы не манагер окон, а , скорее манагер бизнес-логики программы (не знаю как назвать это по другому:) ). Типа События от одного контрола передаются манагеру, а он, соответсвенно их обрабатывает, и изменяет нужные значения других контролов. Естественно даный манагер "знает" обо всех контролах в пределах его подчинения.
Где-то так.
Собственно это был бы не манагер окон, а , скорее манагер бизнес-логики программы (не знаю как назвать это по другому:) ). Типа События от одного контрола передаются манагеру, а он, соответсвенно их обрабатывает, и изменяет нужные значения других контролов. Естественно даный манагер "знает" обо всех контролах в пределах его подчинения.
Где-то так.
Это называется паттерн Mediator.
Короче сделал по правилам и все ОК.
Описание классов для отображения данны в Документе. Отображение этих данных в Виде.
Каждый вид может получить указатель на класс документа, а от туда уже и к данным.
Описание классов для отображения данны в Документе. Отображение этих данных в Виде.
Каждый вид может получить указатель на класс документа, а от туда уже и к данным.