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

VD>Это другая история. Ни КОМ, ни интерфейсы тут не причем.

А я думаю что как раз при чем. Огромное количество интерфейсов привело к тому что и контейнеры требуют разный их набор и сами компоненты редко когда их все реализуют. В результате компонент может работать к примеру в MFC и не работать в VB.

VD>Ну, и на счет не годится вопрос спорный.

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

AVK>>Не уверен. Я пока еще ничего не решил. Посмотрю существующие, потом определюсь.

VD>Очень советую не заниматься созданием с нуля. Уйдеш с головой.

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

VD>Я как бы сам такой, так что тут меня лучше слушать очень внимательно.

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

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

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

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

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

Не надо выдумывать того чего нет. Задача контрола — показать данные и позволить управлять ими. Иначе у тебя окажется что в контрол надо воткнуть вобще все что в янусе есть, потому что там практически один гуй. Окошко для ввода нового сообщения абсолютно независимая от контрола штука, спокойно работает без него и никоим образом в нем не нуждается ни для создлания ни для работы. Оно работает напрямую с БД, а в перспективе наверное с объектной моделью. С какой стати оно должно подчиняться форуму мне не понятно. А почему не outbox, из него ведь его тоже можно вызвать?

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

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

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

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

VD>Собственно никто не запрещает создавать ОО-модель ГУИ. Но все же от фич ее нужно отделать.

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

VD>Каждая фича будет иметь свою ОО-модель, в то время как сами фичи универсальны.

А чем контрол в этом плане выгодным образом отличается от меню? ИМХО ничем.

AVK>>2) 5 кнопок пометки сообщений — прямого отношения к контролу не имеет. Пометка должна производится над объектной моделью, а контрол просто отражать эти изменения. Его участие в этом деле вторично

VD>Кнопка? Да без контрола она вообще смысла не имеет.

Вобще то очень даже имеет.

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

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

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

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

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

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

AVK>>3) Развернуть дерево. Вот это действительно именно контрол, но ты сам же эту опцию заблокировал.

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

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

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

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

VD>Пусть оно будет отдельно от катлет.

А контрол в "катлетах"? Я вот никак логики не уловлю — чем контрол такой особенный?

AVK>>Воздействия из тулбара и меню направлены прежде всего на фичу. Контрол просто один из способов воздействовать на эту же фичу.

VD>Я уже выше сказал почему ты не прав.

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

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

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

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

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

VD>Это попросту его честь.

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

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

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

AVK>>Вот собственно почему? Чем контрол важнее меню?

VD>Он не важнее. Он "определяет весь гуи".

Почему? Вот этого я никак и не могу уловить.

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

VD>Это проблемы контрола.

Ты же агитировал за возможность максимально упростить контрол.

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

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

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

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

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

VD>В терминах твоего MVC

Он не мой, и не надо пытаться меня оскорбить. Давай все таки придерживаться фактов а не эмоций.

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

И что из этого всего следует? То что всю логику надо запихнуть в контрол? Ты совершенно прав, говоря о то что у контрола есть своя модель. Дело в том что структура хорошо спроектированного приложения как правило фрактальна. Нижний уровень это классы, поля класса это модель, интерфейс — вью, а методы контроллер. На верхнем уровне само приложение является MVC. Модель — данные которые оно обрабатывает, вью это весь его интерфейс, а контроллер это весь код. Вот здесь самое главное не напутать с иерархией и не намешать слои. Совершенно очевидно что контроллер должен находится на одном уровне иерархии с моделью, которой он управляет.
Теперь давай посмотрим на фичу. Модель это безусловно те данные, для работы с которыми фича предназначена. В случае форумов это собственно объектная их модель. Вьюхой вроде бы как является контрол. А где котроллер? Вот тут то и оказывается каша, контроллер у нас уполз на более низкий уровень иерархии к контролу. Получается что этот уровень иерархии незаполнен, а более низкий уровень контрола перегружен. Т.е нормальным дизайном было бы создание того чего у нас просто нет — контроллера. Вариантов этого много — можно создать отдельный класс, можно нагрузить его функциоанльностью фичу. Теперь куда же нам девать менюхи и тулбары? Как ты правильно заметил, на уровне фичи это безусловно вью. Но вот работают то они не с моделью контрола, а с моделью фичи, то есть на одном уровне иерархии с контролом. Правда действительно часть меню работает именно с внутренней моделью контрола. То есть получается что мы пытаемся совместить принципиально два разных уровня — управление контролом и управление моделью фичи. ВОт здесь действительно противоречие, однако не думаю что упихивание всего в контрол является хорошей идеей. Можно наверное заставить контрол отдавать свои элементы управления, а фичу свои, можно внутри контрола создать минитулбар, объединив его с кнопками простановки оценок. В общем решений может быть много.

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

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