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