А тебе не кажется, что всю твою идею и то как ты её описал можно представить одной фразой:
"Нажимая на один контрол я хочу что бы изменялись многие"
Так ?
Тогда я не понимаю всех твоих проблемм. У тебя есть внутренее представление состояния твоей программной системы.
Нажимая котрол(ы) ты управляешь этим состоянием. А посылая контролам сообщение Update перересовываешь их в соответствие с этим состоянием.
Говоря другими словами: в обработчике WM_COMMAND кнопки ты меняешь какие то структуры (не думая о других элементах UI) а в конце рассылаешь "броадкастный" WM_UPDATE. Обрабочик этого сообщения каждого контрола сам все и отрисует у себя как надо.
>Обработчики
> кнопки CPage1::CButton m_StartEdit на закладке CPage1 не
> могут непосредственно повлиять, например, на состояние
> чекбоксов или эдитов на закладке CPage2, т.к. она (кнопка)
> не знает даже указателя на диалог CPage2. При переводе
> приложения в режим редактирования данных мы не сможем
> простым путём изменить состояние контролов других,
> «НЕЗАВИСИМЫХ» объектов, например, сделать их
> ReadOnly(false).
И слава богу что не можем... а то бы такого наворотили... И вообще, имхо, "горизонтали" - это зло. Все должно идти с верху в низ, и с низу в верх. Никаких горизонтальных связей !
>Если бы указатель был известен (например,
> мы сделали extern CPage2* Page2),
ага, а я знаю орлов которые с перепоя в какой нибудь ф-ии этот указатель тебе запросто невалидным сделают.... а ты потом все выходные проведешь в поиске ошибки.
> В
> БОЛЬШИХ ПРОЕКТАХ, КОГДА НЕОБХОДИМО СИНХРОНИЗИРОВАТЬ
> ПОВЕДЕНИЕ БОЛЬШОГО ЧИСЛА ЭЛЕМЕНТОВ УПРАВЛЕНИЯ, КОНТРОЛЫ НЕ
> ДОЛЖНЫ ИЗМЕНЯТЬ СОСТОЯНИЕ ДРУГИХ КОНТРОЛОВ !!!НАПРЯМУЮ!!!.
> Т.е. попытка непосредственно в ТЕЛЕ обработчика нажатия
> кнопки порулить состоянием других контролов НАПРЯМУЮ почти
> всегда приведёт к краху в будущем по мере разрастания
> крупного проекта.
Ты знаешь а я вчера на карте Америку обнаружил ! Вот ведь... :))))
> Вот дополнения к мотивации:
> а) объекты и контролы приложения, должны реагировать,
> как правило, на события и состояния БИЗНЕС-ЛОГИКИ
> приложения. Думаю, достаточно определить не слишком большое
> число состояний enum app_state {ST_STARTUP, ST_CLOSE,
> ST_READ, и т.д.} myapp_state.
Правильно, а все же если отделить отображение от данных ? Что если безнесс логика меняет структуры внутрение, а котрол получая лишь одно сообщение, на основе этих структур, перересовывается ? Мож так все же проще ?
> б) сотояние контролов должно зависеть на уровне
> логики приложения от app_state, а не от действий
> пользователя, например, нажатия клавиши мыши. Контрол может
> менять состояние app_state, и таким образом ОПОСРЕДОВАНО
> своё состояние. Т.е схема такова –
> (пользователь)->(нажатие на кнопку)->(изменения
> app_state)->(изменение состояния контрола, enable?
> readonly? и.д.)
Если это то же самое о чем я толкую, то нахрена я все это пишу...
> в) передачу информации между объектами приложения о
> состоянии app_state разумно, на мой взгляд, выполнять в
> виде передачи сообщений app_message {UM_STARTUP, UM_CLOSE,
> UM_READ, и т.д.} myapp_message. Каждому значению app_state
> можно поставить в соответствие значение app_message.
Нафига три, где достаточно одного ?
P.S. Дальше без комментариев... если честно, то дурно стало ;)))
|
подробно о проекте
Анализ криптографических сетевых...
новое сообщение
закрытая нитка
новое сообщение
в закрытой нитке
старое сообщение
