Здравствуйте, AndrewVK, Вы писали:

AVK>Ну запусти шарповский компонент в VB 6.

Еще раз поворю, что на эту тему я дисктировать с тобой отказываюсь. По крайней мере тут. Ты намерено пытаешся сменить тему разговора переведя ее в демагогию. Заводи отдельный топик в форуме по КОМ-у и тебе квалифицированно все разяснят.

AVK>Ну ребар не такой уж ужасный контрол, scintilla покруче будет. Я ж не хочу писать свой ребар, всего лишь раппер.

Не, если жаждешь продолжительного сурового бесплатного сэкса, то тогда конечно. Но проще попровить готовый.

AVK>В общем я поковырялся. Все еще хуже. Дело то как оказывается не в обертках, а в самом ребаре. У него просто нет возможности программно менять положение бендов. Можно управлять только размерами и свойством Break. Все. Студия использует офисный ребар, похоже это не тот что в comctl. В общем МС казлы.

Блин, я тебе вроде привел список событий.

RB_GETRECT — позволяет получить положение бэнда.
RB_SIZETORECT — переместить бэнд в позицию.

А ты какую-то фигню про RB_SETBARINFO начал сотреть.

То что ребары можно помещать на нужные места — это 100%. И IE, и OE используют именно ребоары и прекрасно запоминают позицию.








VD>А к фиче оно имеет отношение?

AVK>Несомненно. Сообщение то в форум пишется, который как раз фича и представляет.

Ты путаешь ГУИ и модель данных. Форум к тулбарам отношения иметь не должен. Форум — это ОО-модель данных. А тулбар представитель ГУИ. И мешать их не нужно.

VD>Диалог нового сообщения является частью гуи фичи. А гуи — это как раз задача контрола.

AVK>Не надо выдумывать того чего нет.

Такое ощущение, что ты сам с собой разговариваешь.

AVK> Задача контрола — показать данные и позволить управлять ими.

Контрол наш, мы ему задачи и будем ставить.

AVK> Иначе у тебя окажется что в контрол надо воткнуть вобще все что в янусе есть, потому что там практически один гуй.

Не окажется. Каждая фича имеет свой гуи. Ну, и гуи может иметь свою ОО. Вот только к данным она не относится.

AVK> Окошко для ввода нового сообщения абсолютно независимая от контрола штука, спокойно работает без него и никоим образом в нем не нуждается ни для создлания ни для работы.

Контрол отвечает за весь ГУИ фичи. Так что если окно имеет отношение к ГУИ фичи, значит она имеет отношение к этому контролу. При другой активной фиче форум на задан, и стало быть данная функция (а окно это не более чем функция) не получит полного списка аргументов.

AVK> Оно работает напрямую с БД, а в перспективе наверное с объектной моделью. С какой стати оно должно подчиняться форуму мне не понятно.

Да с такой. Если фичи будут независимы, то все действия будут отноститься к ним. При активном поиске создание нового сообщения вявляется довольно маразматической ситуацией. А кнопка поиска глупостью в форуме. Еще раз могу повторить, что это окно есть ни что иное как часть ГУИ фичи. Вернее одна из функций этого гуи.

AVK>А почему не outbox, из него ведь его тоже можно вызвать?

В outbox-е попросту не будет понятия активного форума. А без этого понятия создать сообщение невозможно (ответ подавно). Если же в самой форме можно выбрать форум и окно не привязано к форуму, то это уже ГИУ всего приложения и к фичи оно отношение не имеет. Тогда его просто нужно вынести в глобальное меню. Причем это справедлив даже если сама фича будет отдавать меню и обрабатывать его команды. Так, что это очередное притягивание за уши. Я же говорю, о том, что негоже совмещать модель данных и их ГУИ.

А контекстные меню и тулбар (о которых и идет речь) являются частью ГУИ фичи. Ну, а гуи фичи инкапсулирован в контроле.


Фича является частью ОО-модели. Она не должна иметь тесной связи с ГУИ. Чем меньше связь между фичей и ГУИ, тем проще будет развивать приложение.

VD>Если мы хотим сделать хоум универсальным, нужно стараться не интегрировать гуи фич и код формы.

AVK>Ну так о том и речь. Вот только меню и тулбар это не код формы совершенно, а совершенно отдельный функционал, стоящий наравне с контролом фичи.

Меню и тублары это ГУИ. Им не место в ОО-данных.

AVK>Даже визуально они вполне равноправны и никоим образом не подчинены один другому.

Не даже, только. Толко визально они стоят отдельно и равноправны. Реально же они подченены логике ГУИ, которая... ну ты дагадался.

VD>Сам по себе ответ конечно желательно было бы оформить в виде метода у Msg. Но гуи к нему это уже другой вопрос.

AVK>Кто бы спорил. Я только не пойму почему гуй это обязательно контрол.

ГУИ — это не только контрол. Я просто инкапсулировал связь с ГУИ для фичи в виде одной ссылки. Именно, чтобы не свызывать ОО-модель данных и ОО-модель гуи. ОО-модель ГУИ мы вообще толком не обдумывали. Сейчас ведется только переползание на хотя бы каую-нибудь ОО-моедь. У нас пока даже ОО-модель данных до конца не создана. Так нет модели аутбокса и поска. А так же большинство изменений БД делаются в обход ОО-модели. Короче, работать еще есть над чем. Но вот если мы будем сваливать в кучу ГУИ и ОО-модель, то получим задницу.

AVK> Ты же сам себе противоречишь. Хочешь чтобы контрол был как можно сильнее отвязан от специфики фич, но тем не менее зачем то навешиваешь на него лишний функционал.

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

AVK>А чем собственно меню в этом плане отличается от контрола?

Тем, что меню не является полноценным объектом. Меню это всего лишь вью (в любимой тобой MVC) и ему требуется код обрабатывающий события. И этот код очень гармонично ложится в контрол. Таким образом в терминах тай же MVC контрол яляется одновременно вью (так как содержит контролы) и контроллером (так как содерижит обработчики и логику ГУИ), а меню попросту не полноценно. И нет никаких причин чтобы контрол не мог бы стать контроллером для меню и тулбара. А вот фича тут быть контроллером не должна. Ну, а тупо перекладывать ссылки на меню из контрола — бессмысленно.

AVK>Не хочешь помещать код создания меню в фичу? Ну тогда можно создать отдельный класс, который будет этим заниматься.

Я тебя удевлю. Такой класс уже создан. Это и есть контрол. Естественно в самом абстактном виде. Почему? Да потому, что контрол нужен в 99%-ов случаев. Кстати схема должна работать и без контрола. Можно даже сделать так, чтобы перед работой с ним как с контролом проверялоь является ли он контролом и если нет, не работать.

AVK> Хотя сейчасO создание меню или тулбара это ровно одна строчка.

Это к делу не относится.

AVK>Вот только зачем перегружать фунциональностю контрол, который уже сейчас черезмерно сложен?

Т.е. зачем класть код обработки ГУИ в контрол, а не в модель данных? Ну, я верю, что на этот вопрос ты способен ответить и сам!

VD>Каждая фича будет иметь свою ОО-модель, в то время как сами фичи универсальны.
AVK>А чем контрол в этом плане выгодным образом отличается от меню? ИМХО ничем.

Тем, что он и является инкасулюцией ГУИ фичи. У приложения есть два варианта представления: 1) ОО-модель данных, 2) ОО-модель ГУИ. Связь между ними (а главное зависимость данных от гуи) должна быть минимальна. Тогда можно будет работать с приложением программно не натыкаясь то и дело на ГУИ. По идее все диалоги нужно оформить в виде методов. Какие-то из диалогов будут относиться к фичам, какие-то к приложению в целом. Тоже самое с тулбаром. Более того! По большому счету приложение — это тоже фича. Просто — это фича которая всегда активна причем параллельно с ней может быть активна и другая фича. Фича это тоо место где ГУИ мапится на ОО-модель данных, но из этого не следует, что в ОО-модель форума нужно пихать меню. Если хочишь сделаем еще список глобальных фич.

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

VD> Если в первом пункте еще можно было говорить об ответе на активное сообещие, то помечаться как прочитанные могут сразу несколько сообщений, а значит эта кнопка зависит от списка выделенных сообщений.

AVK>Не любая. Те, которые помечают все сообщения или по дате никак не подвязаны. Контрол в данном случае является всего лишь дополнительным источником данных, но никак не хозяином.

Перевернул все с ног на голову, перемешал все понятия... и вышла каша. Нет дополнительных и основных. Если одного из источников нет, то работать ничего не будет.

Кнопка имеет отношение толко к гуи форума. А вот сама пометка сообщений как раз функция ОО-модели данных. Точнее часть функционала форума. Обрати вниманеие именно форума как объекта, а не как гуи. Вот ГУИ активируясь должен показать эту кнопку. А при нажатии на нее гуи должен взять все нужные данные и вызвать метод у ОО-модели форума. Т.е. ГУИ как бы является способом взять от пользователя неизвестные параметры для вызова метода.

VD>Выделение не являются частью ОО-модели,

AVK>Совершенно верно, оно является частью модели самого контрола, однако это не единственные данные, с которыми работают эти кнопки.

Думаю, чтобы тебе было проще расслабиться нужно забыть про контрол и говорить только о ГУИ-модели и ОО-модели. Тогда даже не возникнет таких вопросво. Ведь глупо засовывать меню (ГУИ-компонент — думаю, не будешь спорить, что меню это гуи?) в ОО-моедель того же форума. Контрол же является всего лишь полимпорфной связью гуи и ОО-модели.

VD>и стало быть без контрла в этой кнопке смысла нет.

AVK>Без объектной модели впрочем тоже.

Не сомненно. Но у гуи есть полный доступ к ОО-модели. Это ОО-модель нужно беречь от смешивания с ГУИ. А на оборот пожалуста. ГУИ же наоборот нужно беречь, не от ОО-модели, а от прямой работы с данными.

AVK> Однако это же не повод пихать меню туда. Ты пойми — в этой операции конрол выступает подчиненным — у него берут данные и ему приказывают обновиться. Сам же он занимает пассивное положение.

Это не важно. Ведь не ОО-модель им управляет. Им управляет так сказать ГУИ основаной фичи (само приложение). Вернее логика его гуи.

В общем, выресовывается красивая схема. Есть ОО-модель данных. И есть приложение. Приложение читает ОО-модель и отображает данные для пользователя в виде дерева навигации. Далее когда пользователь выбирает фичу гуи формы получает гуи для конкретной фичи (мне вот как раз этот момент меньше всего нравится) и активирует его.

Связь фичи и его гуи нужна в основном для поддержки независимого расширения приложения. Фичу можно добавить динамически и стало быть ее гуи тоже должен добавляться динамически.

AVK>Нет, вот это как раз прямое управление контролом, а никак не сообщениями.

Развивая твою логику сообщения тоже бирутся из ОО-модели.

VD>Ну, я вроде все обяснил. Или ты не понял? К фичам меню точно не отностся. Это гуи.

AVK>Само меню не относится, но обеспечивать его должна именно фича, поскольку именно она обеспечивает контрол, который не меньшее гуи чем меню.

Попробую еще раз (хотя уже очень надоело). Связь между фичей и ее гуи должне быть минимальная. Я остановился на возвращении одного указателя. При этом внутри фича вообще не общается с ГУИ. Да у нее есть события, но сама она ничего не делает. По хорошему нужно было вобще возвращать не ссылку на класс, а идентификатор типа, а созданием гуи должно заниметься основное гуи. Но я делал все не с нуля и в приложении уже нехилвые завязки на экземпляры контролов. Пришлось делать именно так. И по-моему — это самое оптимальное решение на сегодня.


AVK>Ты так и не объяснил почему контрол в этом отношении особенный.

Пытался. Но это как в случае с сервером приложений. Ты свыкся с одни взглядом и не хочешь принимать другой. Я уже несколько раз говорил, что контрол выбран потому, что он фигурирует наиболее часто и именно в нем лежит основной код. По большому счету это должен быть не контрол, а ОО-моделб ГУИ фичи. Так понятно?

VD>Могу попробывать по другому. Фича — это возможность хоума. Она активируется и работа ведется с ней. После активации весь гуи это уже отдельная песня. Фича же полиморфная структура. Нефига на нее цеплять, то о чем ей и знать не интересно.

AVK>А зачем ты нацепил на нее контрол в таком разе?

Связь между фичей и гуи все же нужна. Но я старался сделать ее как можно меньшей. Одна ссылка — это том минимум который мне кажется оправдан.

VD>Обработка меню и тулбаров прераготива контрола.

AVK>Вот собственно почему это так ты все еще не объяснил.

Да потому, что он ГУИ, и меню ГУИ. Меню это часть гуи!

AVK>Это сейчас они его часть. Это ненормально. Представь что у тебя есть MDI приложение, внутри главного окна есть меню и тулбар, а так же подчиненные окна. Следуя твоей логике код тулбара и меню должен быть в компоненте подчиненной формы.

Передергивание не даст тебе ничего полезного. Я тебе уже говорил, что ГУИ фичи должен возвращать только те меню которые относятся именно к нему. Если меню глобальное, то нефига его вообще цеплять к фиче. Это просто ошибка.

AVK>Ну тогда отделяй от нее еще и контрол, оно такое же гуи.

Если бы можно было обеспечить связь между фичей и гуи как-то по другому, я бы это сделал. Похоже тебя заело именно то что я вябрал контрол в качестве базового указатлея. Ну, попробуй воспринимать его как некий пустой интерфейс. Я хочу чтобы в качестве фичи можно было подключить обычный контрол. И по этому приходится возвращать именно контрол, а не обжект или абстрактный интерфейс.

VD>Он не важнее. Он "определяет весь гуи".
AVK>Почему? Вот этого я никак и не могу уловить.

Потому, что так сделано. Меню без контрола быть не может. Тулбара тоже. А вот контрол без них спокойно. Потому и контрол.

AVK>>А ты подумай о том что контрол может быть один и тот же, а меню и тулбары разные.
VD>Это проблемы контрола.
AVK>Ты же агитировал за возможность максимально упростить контрол.

Будут ему нужны тублары возвратит их. Не будут не возвратит. Все равно без контрола некому будет обработать эти самые нажатия на кнопки.

VD>Его внутренняя логика.

AVK>Слушай, ты прямо как не читал то что я писал. Часть воздействий из меню вобще никакого отношения к контролу не имеет.

Все воздействия из меню этого контрола имеют отношения к этому контролу. Если это не так, то ты просто не верно засунул пункт меню. Контрол — это ГУИ фичи. Если фича не активна, то и тубларов видно не будет. Не важно что для обработки нажатия не нужно брать данные из контрола. Он — это сердце гуи. В нем вся обработка. И поэтому он экспортирует меню, а не фича. Фича не имеет права иметь внутри себя гуи. А возвращать просто ссылку на черт занет что бессмысленно.

AVK> С ними как? Представим что их нет? Желание избавится от лишней функциональности в фиче еще не означает что контрол нужно превращать в монстра. ForumDummyForm.cs больше 70К и это уже явная порнография.

Это демагоги. 70К — не проблема. Если реализовать все как следует убрав логику данных из этого файла, он даже похудеет. У нас все файлы измеряются десятками килобайт, ну и что? Совершенно нормально, что главная фича занимает много места. Вот очент странно, что SearchDummyForm.cs занимает 87. Это же только поиск.

AVK>>Вспомни лучше MVC. Контрол это View, отчасти Controller. Зачем ты еще пытаешься навесить на него функции Model мне непонятно.

VD>Ты снова пытаешся приплетать шаблоные
VD>вместо того чтобы думать.

AVK>Ты вобще отдаешь себе отчет в том что ты абсолютно без оснований грубо на меня наехал?

Это не так. Я тбе сказал, что что есть. Ты пытаешся применить шаблон MVC к ситуации которая сложенее его. Я тебе уже не раз говорил, что бездумное применение этих шаблонов ведет к бессмыслице.

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

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

VD>В терминах твоего MVC
AVK>Он не мой, и не надо пытаться меня оскорбить. Давай все таки придерживаться фактов а не эмоций.

Я тебя не оскорбляю, но ты пытаешся всунуть в более сложную модель более простую.

VD>контрол это и вью и контролер в одном флаконе. Да и моедль, если вести речь о ОО-модели ГУИ. В жизни все сложенее. И примитивные концепции можно использовать только на элементарных ее частях.

AVK>И что из этого всего следует? То что всю логику надо запихнуть в контрол?

Всю ГУИ-логику связанную с конкретной фичей.

AVK>Ты совершенно прав, говоря о то что у контрола есть своя модель.

Спасибо за признание!

AVK> Дело в том что структура хорошо спроектированного приложения как правило фрактальна.

У. Тебя потянуло на философию... Молчу, молчу. А то ты меня снова будешь обвинять в оскорблении твоей личности.

AVK> Нижний уровень это классы, поля класса это модель, интерфейс — вью, а методы контроллер.

А. Я то думал. Ну, тогда все впорядке. В шарпе все кроме примитивов — это VMC. А раз так то давай не будем обсуждать такую примитивщину.

AVK>Теперь давай посмотрим на фичу. Модель это безусловно те данные, для работы с которыми фича предназначена. В случае форумов это собственно объектная их модель. Вьюхой вроде бы как является контрол. А где котроллер?

В твоей терминалогии контрол является и контроллером и моделью одновременно. Блее того в нем их множество. Короче, видимо я плохо выразился. Нля представления данной модели шаблон MVC бессмысленнен, так как или привот к абстракции ОО-модель/ГУИ/ГУИ-код или спускается до отдельной кнопки.

AVK> Вот тут то и оказывается каша, контроллер у нас уполз на более низкий уровень иерархии к контролу.

Никакой иерархии нет. Ты это сам придумал.

AVK> Получается что этот уровень иерархии незаполнен, а более низкий уровень контрола перегружен.

Отброся неимеющиеся уровни и применя твою же аналогию могу сказать так: контрол это контролер и спаривать его с моделью не следует.

AVK> Т.е нормальным дизайном было бы создание того чего у нас просто нет — контроллера.

1. То что было вообще дизайном развать нельзя.
2. Обвинение данного дизайна необоснованны.
3. Ты похоже очень странно предсталяешь себе расшифровку этого самого MVC в применении этого шаблона к данной модели.

Попрбую в тоих терминах.

Модель — тут ты угодал. Модль можно сопоставить с ОО-моделью данных. Видимо догадался по названию.
Вью — тут ты промазал. Вью это весь гуи с точки зрения пользователя, т.е. это и меню, и тулбар, и другие контролы коих море. Кстати, грид тоже часть вью.
Котроллер — это код связующий ОО-модель и перечисленные мной контролы.

Проблема в том, что такое представление ничего не дает. И данная моедль (MVC) тут является всего лишь безполезным знанием, так как все намного сложнее чем можно описаь этой моделью. Говорить же, что интерфейс класса — это влью вообще не кооррекно. Вообще аналоги между MVC и классом быть не может. Класс не визульная сущьность, а MVC шаблон рассчитанных на представление УИ.

AVK> Вариантов этого много — можно создать отдельный класс, можно нагрузить его функциоанльностью фичу. Теперь куда же нам девать менюхи и тулбары? Как ты правильно заметил, на уровне фичи это безусловно вью. Но вот работают то они не с моделью контрола, а с моделью фичи,

Ошибаешся. Работает он с моделью данных (фича только часть этой модели) по средсвам кода который и является в твоей терминологии контроллером.

AVK> то есть на одном уровне иерархии с контролом. Правда действительно часть меню работает именно с внутренней моделью контрола. То есть получается что мы пытаемся совместить принципиально два разных уровня — управление контролом и управление моделью фичи.

Я то ничего не путаю. Это ты путаешь. Слава богу похоже ты заметил, что заблуждается вот только хвотил ли смелости в этом признаться.

А вот ты заблуждаешся. Мнею не работает с моделью контрола. Меню это контрол дающий сигнал (так вроде в MVC события называют?) конроллеру реализованному в коде ГУИ (лежащем в контроле) на выполнение тех или иных действий.

Просто нужно понять, что тут или смесь этого самого контроллера с вью или море мелких контроллеров и вью.

Что же касается неотносщихся к "контролу" пунктов меню, то или они попали не по назначению, так как не относятся к активной фиче, или они являются частью ГУИ фичи, но просто не требуют дополнительного контекста.

AVK> ВОт здесь действительно противоречие, однако не думаю что упихивание всего в контрол является хорошей идеей.

Поверь, куда более лучшей чем приметивный MVC.

AVK> Можно наверное заставить контрол отдавать свои элементы управления, а фичу свои, можно внутри контрола создать минитулбар, объединив его с кнопками простановки оценок. В общем решений может быть много.

Заставляя фичу отдавать элементы управления ты будешь вынужден слить обработку событий от них с логикой данных. Или перенаправлять эти события во вне (например, тому же контролу). Кривойсть этого была прекрасно видна после твоих переделок. Ведь если следовать твоей логике контол не имеет права обрабатывать события от мню, а у тебя было именно так. Если попытаться избавиться от этого, то получится, что события должена будет обрабатывать фича, но она же редставление модели данных! И это прямое нарушение той же модели MCV (ничего, что я ею спекулирую ? ).

Если же посмотреть под углом той же MVC, но подругому, можно заметить, что фича будет моделью данных, а контроллеры и влью будут переплетены в контрле. Причем не важно, что это контрол. Важно, что это код ГУИ отделенный от данных. Ну, а связь между ГУИ и фичей ни что иное, как некая мета-связь позволяющая подгружать ГУИ для фичи на основании типа фичи.

AVK>А как быть к примеру с пометкой всех сообщений форума?

Это тоже не сомненно часть ГУИ фичи, и так как контрол является реализацией этго гуи, он и должен контролировать эту фнкцию.

Последний раз на последок. Контрол воспринимается мною как код содержащий ГУИ для отдельно взятой фичи. Только для нее! Но в то же время весь код гуи, т.е. не только то что делается визульно. При этом тулбары воспринимаются как часть этого гуи которую просто не удается запихнуть в рамки прямоугольного простарнства самого контрола. Ну, а контрол был выбран исключительно из-за универсальности. Так как минимальным ГУИ для ичи является именно контрол.

Самое смешное, что у в хоуме даже не пришлось много переделывать, так как решение о запихивании ГУИ фич в контролы принял ты. Ты даже не знал о том, что это гуи для фичь, но сделал это! Так как это просто оподсказывает интуиция.