Да. И похоже ты залепил поддержку Гуи прямо в IFeatureGui. Еще раз повторяю. Не нужно их туда пихать. Пусть будет можно делать фичи не знающие о меню. Это уже пускай контрол говорит о том какие меню он хочет экспортировать. И то это должно бтыь не обязательно.
Я специально ввел интерфейс ISupportGuiBars. Суй поддержку меню и тулбаров именно в него а не в IFeatureGui.
Ну, и разберись с файлам. А то я скомпилироваться немогу после твоего комита.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Да. И похоже ты залепил поддержку Гуи прямо в IFeatureGui.
Тыж его сам гуем обозвал. Как будто единственный метод, возвращающий Control не гуй. Чего кучу интерфейсов плодить?
VD>Еще раз повторяю. Не нужно их туда пихать. Пусть будет можно делать фичи не знающие о меню.
А их и так можно делать. В базовом контроле просто возвращается null.
VD>Я специально ввел интерфейс ISupportGuiBars.
Ты переименовал старый IChildForm. Я не хочу его трогать, порскольку полноценной замены тулбару пока нет.
Здравствуйте, AndrewVK, Вы писали:
VD>Да. И похоже ты залепил поддержку Гуи прямо в IFeatureGui.
AVK>Тыж его сам гуем обозвал. Как будто единственный метод, возвращающий Control не гуй. Чего кучу интерфейсов плодить?
Гуй. Но одно дело контрол требовать, а другое довольно сложные меню, которые зависят от компонентов третьих поставщиков. По моей задумке в качестве фичи можно будет засунуть обычный контрол. Причем это может быть контрол не заточенный специально под Хоум. Ну, а если контрол хочет менюшку или сообщения, то пусть реализует интерфейсы ISupportGuiBars и IFeatureView.
Еще раз:
— позволяет получать уведомления об активации фичи, обновлении данных и изменении конфига.
public interface IFeatureGui
{
/// <summary>
/// Возвращает контрол который будет использоваться для взаимодействия
/// с фичей.
/// </summary>
Control GuiControl{get;}
void ConfigChanged();
}
— позволяет (контролу) предоставить меню и тулбар.
Обрати внимание, что эти интерфейсы рассчитаны на реализацию их в контроле, а не в фиче. Причем если контрол их не поддерживает, он просто не получает соответсвующих услуг, но может работать и так. Например, тем же линкам это все на фиг не упало.
VD>Еще раз повторяю. Не нужно их туда пихать. Пусть будет можно делать фичи не знающие о меню. AVK>А их и так можно делать. В базовом контроле просто возвращается null.
Нет. Мне прийдется цеплять к себе ссылку на эти интерфейсы и на Мэйджик. А так можно в качестве конрола использовать любой конрол. Хоть листбокс .
VD>Я специально ввел интерфейс ISupportGuiBars.
AVK>Ты переименовал старый IChildForm. Я не хочу его трогать, порскольку полноценной замены тулбару пока нет.
Ну, и введи ISupportGuiBars2. В чем проблема?
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Гуй. Но одно дело контрол требовать, а другое довольно сложные меню,
"сложные меню" значительно проще контрола.
VD>которые зависят от компонентов третьих поставщиков.
Нет внутри януса никаких третьих поставщиков. Меню в янусе только такое и больше никакого другого.
VD>По моей задумке в качестве фичи можно будет засунуть обычный контрол. Причем это может быть контрол не заточенный специально под Хоум.
Ну и зачем?
AVK>>Ты переименовал старый IChildForm. Я не хочу его трогать, порскольку полноценной замены тулбару пока нет.
VD>Ну, и введи ISupportGuiBars2. В чем проблема?
Не хочу интерфейсы плодить. В любом случае развести один интерфейс по двум минутное дело.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, VladD2, Вы писали:
VD>Гуй. Но одно дело контрол требовать, а другое довольно сложные меню,
AVK>"сложные меню" значительно проще контрола.
Блин. Ты про абстракцию слышал? Тогда не городи ерунды. Речь не о сложности. Речь о универсальности. Подход должен быть такой. Нужно контролу меню — пусть реализует ISupportGuiBars2. Нужно ему получать уведомления — пусть реализует IFeatureView. А не нужно, так не нужно. При этом можно будет простой контрол использовать (чужой).
VD>которые зависят от компонентов третьих поставщиков.
AVK>Нет внутри януса никаких третьих поставщиков. Меню в янусе только такое и больше никакого другого.
Мэджик. Именно в меню.
VD>По моей задумке в качестве фичи можно будет засунуть обычный контрол. Причем это может быть контрол не заточенный специально под Хоум.
AVK>Ну и зачем?
Закачем. А зачем тебе интерфейс вместо Msg? За тем же. Для абстрации. Чтобы человек мог быстро стартовать. Создать контол, бросить в каталог и увидеть результат. Ну, а потом потихоничку допишет все что ему нужно. А не нужно не сделает лишних действий. В общем, концепция в том, чтобы не писать минимум кода потом.
AVK>Не хочу интерфейсы плодить. В любом случае развести один интерфейс по двум минутное дело.
Блин. Еще раз. Слушай внимательно! IFeatureGui — реализуется фичей, а ISupportGuiBars2 (который должен отдавать меню) самим контролом и только если эти меню ему нужны. Понял? Ненадо пихать в фичу меню. Она даже создать список менюшек как следует не сможет. Пусть этим контрол занимается.
Ну, а пложение интерфейсов... Чем меньше интерфейс тем проще его реализовать. Так что это плюс. Это не классы плодить.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Блин. Ты про абстракцию слышал? Тогда не городи ерунды. Речь не о сложности. Речь о универсальности. Подход должен быть такой. Нужно контролу меню — пусть реализует ISupportGuiBars2. Нужно ему получать уведомления — пусть реализует IFeatureView.
И на каждый чих свой интерфейс? Очень странный дизайн. Я такое видел только в СОМ, там тоже в ActiveX может быть реализовано пару десятков интерфейсов. Ничего хорошего я в этом не вижу. У МС вон даже родные контейнеры между собой несоместимы.
AVK>>Нет внутри януса никаких третьих поставщиков. Меню в янусе только такое и больше никакого другого.
VD>Мэджик. Именно в меню.
Это не мэджик. В нем нет тулбаров. Вобще с тулбарами проблема — ни один бесплатный не умеет позиционировать бары внутри ребара. Задница. Видимо придется свой писать.
VD>>По моей задумке в качестве фичи можно будет засунуть обычный контрол. Причем это может быть контрол не заточенный специально под Хоум.
AVK>>Ну и зачем?
VD>Закачем.
Мда, аргументированно.
VD>А зачем тебе интерфейс вместо Msg? За тем же. Для абстрации.
Не понял. Засунуть в качестве фичи контрол для абстракции. Мда, звучит, но практическая польза от сих извращений все равно непонятна.
VD>Чтобы человек мог быстро стартовать. Создать контол, бросить в каталог и увидеть результат.
И чего он увидит?
VD>Ну, а потом потихоничку допишет все что ему нужно. А не нужно не сделает лишних действий. В общем, концепция в том, чтобы не писать минимум кода потом.
Ладно, бог с ним, разнесу на два интерфейса.
VD>Блин. Еще раз. Слушай внимательно! IFeatureGui — реализуется фичей, а ISupportGuiBars2 (который должен отдавать меню) самим контролом и только если эти меню ему нужны.
Вот это уже чепуха. Менюшки нужны не контролу а именно фиче. Менюшки вставляются не в контрол, а в сам янус и имеют отношение именно к фиче. Более тгго — в принципе возможна ситуация когда есть менюшка и нет контрола.
VD>Понял? Ненадо пихать в фичу меню. VD>Она даже создать список менюшек как следует не сможет.
Контрол может создать, значит и менюшки может. Нет никакой принципиальной разницы между контролом и менюшкой. И то и другое элементы управления.
VD> Пусть этим контрол занимается.
Здравствуйте, AndrewVK, Вы писали:
AVK>И на каждый чих свой интерфейс? Очень странный дизайн. Я такое видел только в СОМ,
Да. Убедил КОМ — это никуда не годится. Там уроды все писали. Они же безграмотные. То ли дело профы из Дельфи! Хотя и туда интерфейсов по напихили.
AVK> там тоже в ActiveX может быть реализовано пару десятков интерфейсов. Ничего хорошего я в этом не вижу. У МС вон даже родные контейнеры между собой несоместимы.
Очень убедительно. Жаль никакого отношения к делу не имеет.
Почитай Буча. И других ОО-классиков.
AVK>Это не мэджик. В нем нет тулбаров. Вобще с тулбарами проблема — ни один бесплатный не умеет позиционировать бары внутри ребара. Задница. Видимо придется свой писать.
Точно! Тебе больше заняться нечим? Или считаешь, что по новой быстрее написать, чем имеющиеся поправить?
AVK>И чего он увидит?
Короче, тебе охота докопатсья. Тебе что не скжи у тебя один вопрос зачем? Зачем я тебе я тебе уж сказал. Не хочешь понимать, твои проблемы. У тебя есть аргументы против? Нет, ну тогда пусть будет так. Считай что я так хочу.
AVK>Ладно, бог с ним, разнесу на два интерфейса.
Я уже разнес.
VD>Блин. Еще раз. Слушай внимательно! IFeatureGui — реализуется фичей, а ISupportGuiBars2 (который должен отдавать меню) самим контролом и только если эти меню ему нужны.
AVK>Вот это уже чепуха. Менюшки нужны не контролу а именно фиче.
Нахрен они ей? Ты не заметил, что ты их из контрола один хрен береш? Это как раз потому, что они есть часть этого конрола. Это его тублары. Он на них будет реагировать. Он же их настравивает.
AVK> Менюшки вставляются не в контрол, а в сам янус и имеют отношение именно к фиче. Более тгго — в принципе возможна ситуация когда есть менюшка и нет контрола.
Да хоть в анус они будут вставляться. Фича отдала свой гуи в виде абстракции — контрола. Дальше гуи — это пооблемы этого контрола. Ему сама фича может быть даже не нужна.
VD>Понял? Ненадо пихать в фичу меню. VD>Она даже создать список менюшек как следует не сможет.
AVK>Контрол может создать, значит и менюшки может. Нет никакой принципиальной разницы между контролом и менюшкой. И то и другое элементы управления.
Вот пусть он и моежт. Корче, я уже сдалал как надо.
VD> Пусть этим контрол занимается.
AVK>Очень странная логика.
Нормальная логика. Погляди как через ухо ты сделал. Фича отдает тублар который реально берется из контрола. При этом фича завязывается на контрол. Она так же вынвждена быть завязана на меню. А так получается стройная концепция. Фича обязана знать только о контроле. Контрол определяет весь гуи. При этом он может вообеще незнать о наших заморочках. Например, какие-нибудь линки без пробелм могут быть отдельным контролом. Если же контролу требуется отобразить меню или тулбар он отдает интерфейс.
Ты лучше вот о чем подумай. Иногда контролу нужно будет изменить тулбар или меню прямо на ходу. Этом ожно будет сделать или нажно еще что-то придумать.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD> Да. Убедил КОМ — это никуда не годится.
Его катавасия с ActiveX никуда не годится.
AVK>>Это не мэджик. В нем нет тулбаров. Вобще с тулбарами проблема — ни один бесплатный не умеет позиционировать бары внутри ребара. Задница. Видимо придется свой писать.
VD>Точно! Тебе больше заняться нечим? Или считаешь, что по новой быстрее написать, чем имеющиеся поправить?
Не уверен. Я пока еще ничего не решил. Посмотрю существующие, потом определюсь.
AVK>>Вот это уже чепуха. Менюшки нужны не контролу а именно фиче.
VD>Нахрен они ей? Ты не заметил, что ты их из контрола один хрен береш? Это как раз потому, что они есть часть этого конрола. Это его тублары. Он на них будет реагировать. Он же их настравивает.
Ну вобще то уже сейчас многие кнопки имеют отношение не к контролу, а именно к объектной модели. Просто ввиду того что раньше вся логика ьыла только в контрролах они привязываются к контролу. Вот давай посмотрим к примеру тулбар форума
1) Новое сообщение, реплай. Однозначно не имеет никакого отношения к контролу. Он даже никак на них не реагирует. То что сейчас этот код в контроле это неверный дизайн.
2) 5 кнопок пометки сообщений — прямого отношения к контролу не имеет. Пометка должна производится над объектной моделью, а контрол просто отражать эти изменения. Его участие в этом деле вторично
3) Развернуть дерево. Вот это действительно именно контрол, но ты сам же эту опцию заблокировал.
4) Навигация по истории. Вот наверное единственные кнопки, которые можно без оговорок отнести к контролу.
5) В меню есть еще сохранение сообщения. Опять же — никакого отношения к контролу.
Итак, в итоге большинство воздействий прямого отношения не имеют. А иногда вобще никакого отношения.
Вот поэтому меню и тулбар это несомненно свойства именно фичи, а не контрола.
VD>Да хоть в анус они будут вставляться. Фича отдала свой гуи в виде абстракции — контрола. Дальше гуи — это пооблемы этого контрола. Ему сама фича может быть даже не нужна.
Воздействия из тулбара и меню направлены прежде всего на фичу. Контрол просто один из способов воздействовать на эту же фичу.
AVK>>Контрол может создать, значит и менюшки может. Нет никакой принципиальной разницы между контролом и менюшкой. И то и другое элементы управления.
VD>Вот пусть он и моежт. Корче, я уже сдалал как надо.
Это неверное решение.
AVK>>Очень странная логика.
VD>Нормальная логика. Погляди как через ухо ты сделал. Фича отдает тублар который реально берется из контрола.
Это недоделки. Фича же должна его и генерить.
VD>При этом фича завязывается на контрол. Она так же вынвждена быть завязана на меню. А так получается стройная концепция. Фича обязана знать только о контроле. Контрол определяет весь гуи.
Вот собственно почему? Чем контрол важнее меню?
VD> При этом он может вообеще незнать о наших заморочках. Например, какие-нибудь линки без пробелм могут быть отдельным контролом. Если же контролу требуется отобразить меню или тулбар он отдает интерфейс.
А ты подумай о том что контрол может быть один и тот же, а меню и тулбары разные.
VD>Ты лучше вот о чем подумай. Иногда контролу нужно будет изменить тулбар или меню прямо на ходу.
Вспомни лучше MVC. Контрол это View, отчасти Controller. Зачем ты еще пытаешься навесить на него функции Model мне непонятно.
Здравствуйте, AndrewVK, Вы писали:
VD> Да. Убедил КОМ — это никуда не годится.
AVK>Его катавасия с ActiveX никуда не годится.
Это другая история. Ни КОМ, ни интерфейсы тут не причем. Ну, и на счет не годится вопрос спорный. Все работает. Другое дело что документировано все плохо.
AVK>Не уверен. Я пока еще ничего не решил. Посмотрю существующие, потом определюсь.
Очень советую не заниматься созданием с нуля. Уйдеш с головой. Я как бы сам такой, так что тут меня лучше слушать очень внимательно.
AVK>Ну вобще то уже сейчас многие кнопки имеют отношение не к контролу, а именно к объектной модели. Просто ввиду того что раньше вся логика ьыла только в контрролах они привязываются к контролу. Вот давай посмотрим к примеру тулбар форума AVK>1) Новое сообщение, реплай. Однозначно не имеет никакого отношения к контролу. Он даже никак на них не реагирует. То что сейчас этот код в контроле это неверный дизайн.
А к фиче оно имеет отношение? Диалог нового сообщения является частью гуи фичи. А гуи — это как раз задача контрола. Если мы хотим сделать хоум универсальным, нужно стараться не интегрировать гуи фич и код формы. Сам по себе ответ конечно желательно было бы оформить в виде метода у Msg. Но гуи к нему это уже другой вопрос.
Собственно никто не запрещает создавать ОО-модель ГУИ. Но все же от фич ее нужно отделать. Каждая фича будет иметь свою ОО-модель, в то время как сами фичи универсальны.
AVK>2) 5 кнопок пометки сообщений — прямого отношения к контролу не имеет. Пометка должна производится над объектной моделью, а контрол просто отражать эти изменения. Его участие в этом деле вторично
Кнопка? Да без контрола она вообще смысла не имеет. Если в первом пункте еще можно было говорить об ответе на активное сообещие, то помечаться как прочитанные могут сразу несколько сообщений, а значит эта кнопка зависит от списка выделенных сообщений. Выделение не являются частью ОО-модели, и стало быть бещ контрла в этой кнопке смысла нет.
AVK>3) Развернуть дерево. Вот это действительно именно контрол, но ты сам же эту опцию заблокировал.
Не более чем предыдущее. Ну, а заблокировал ты и сам знаеш почему.
AVK>4) Навигация по истории. Вот наверное единственные кнопки, которые можно без оговорок отнести к контролу. AVK>5) В меню есть еще сохранение сообщения. Опять же — никакого отношения к контролу. AVK>Итак, в итоге большинство воздействий прямого отношения не имеют. А иногда вобще никакого отношения. AVK>Вот поэтому меню и тулбар это несомненно свойства именно фичи, а не контрола.
Ну, я вроде все обяснил. Или ты не понял? К фичам меню точно не отностся. Это гуи. Пусть оно будет отдельно от катлет.
VD>Да хоть в анус они будут вставляться. Фича отдала свой гуи в виде абстракции — контрола. Дальше гуи — это пооблемы этого контрола. Ему сама фича может быть даже не нужна.
AVK>Воздействия из тулбара и меню направлены прежде всего на фичу. Контрол просто один из способов воздействовать на эту же фичу.
Я уже выше сказал почему ты не прав. Могу попробывать по другому. Фича — это возможность хоума. Она активируется и работа ведется с ней. После активации весь гуи это уже отдельная песня. Фича же полиморфная структура. Нефига на нее цеплять, то о чем ей и знать не интересно.
Обработка меню и тулбаров прераготива контрола. Это попросту его честь. Просто мы создали механизм позволяющий часть его размещать вне него.
VD>Нормальная логика. Погляди как через ухо ты сделал. Фича отдает тублар который реально берется из контрола.
AVK>Это недоделки. Фича же должна его и генерить.
Ага. Доделки будут тогда когда ты будешь передавать управление при вызове кномки в контрол и обратно. Дурь да и только. Пусть каждый занимется своим. Фича обеспечивает возможности, а гуи живет своей жизнью.
VD>При этом фича завязывается на контрол. Она так же вынвждена быть завязана на меню. А так получается стройная концепция. Фича обязана знать только о контроле. Контрол определяет весь гуи.
AVK>Вот собственно почему? Чем контрол важнее меню?
Он не важнее. Он "определяет весь гуи".
VD> При этом он может вообеще незнать о наших заморочках. Например, какие-нибудь линки без пробелм могут быть отдельным контролом. Если же контролу требуется отобразить меню или тулбар он отдает интерфейс.
AVK>А ты подумай о том что контрол может быть один и тот же, а меню и тулбары разные.
Это проблемы контрола. Его внутренняя логика. Мы этому просто не должны мешать. Но независимость — это всегда хорошо (если не приводит к тормозам).
VD>Ты лучше вот о чем подумай. Иногда контролу нужно будет изменить тулбар или меню прямо на ходу.
AVK>Вспомни лучше MVC. Контрол это View, отчасти Controller. Зачем ты еще пытаешься навесить на него функции Model мне непонятно.
Ты снова пытаешся приплетать шаблоные вместо того чтобы думать. В терминах твоего MVC котрол это и влью и контролер в одном флаконе. Да и моедль, если вести речь о ОО-модели ГУИ. В жизни все сложенее. И примитивные концепции можно использовать только на элементарных ее частях.
Функции же будет пытаться наложить жизнь. Если у меня, например, нет выделенных строк, то и мометить сообщения как прочитанные я не имею права. При этом, было бы есетсвенно если соответсвующая кнопка была бы задизэйблена.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, 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>Функции же будет пытаться наложить жизнь. Если у меня, например, нет выделенных строк, то и мометить сообщения как прочитанные я не имею права.
А как быть к примеру с пометкой всех сообщений форума?
Здравствуйте, 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>А как быть к примеру с пометкой всех сообщений форума?
Это тоже не сомненно часть ГУИ фичи, и так как контрол является реализацией этго гуи, он и должен контролировать эту фнкцию.
Последний раз на последок. Контрол воспринимается мною как код содержащий ГУИ для отдельно взятой фичи. Только для нее! Но в то же время весь код гуи, т.е. не только то что делается визульно. При этом тулбары воспринимаются как часть этого гуи которую просто не удается запихнуть в рамки прямоугольного простарнства самого контрола. Ну, а контрол был выбран исключительно из-за универсальности. Так как минимальным ГУИ для ичи является именно контрол.
Самое смешное, что у в хоуме даже не пришлось много переделывать, так как решение о запихивании ГУИ фич в контролы принял ты. Ты даже не знал о том, что это гуи для фичь, но сделал это! Так как это просто оподсказывает интуиция.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Attempts to find the best layout of the bands for the given rectangle.
Parameters
wParam
Must be zero.
prc
Pointer to a RECT structure that specifies the rectangle to which the rebar control should be sized.
VD>То что ребары можно помещать на нужные места — это 100%. И IE, и OE используют именно ребоары и прекрасно запоминают позицию.
Вопрос в том как они это делают. Точнее IE 6 вобще не позволяет таскать тулбары, а вот OE действительно запоминает позицию.
VD>>А к фиче оно имеет отношение?
AVK>>Несомненно. Сообщение то в форум пишется, который как раз фича и представляет.
VD>Ты путаешь ГУИ и модель данных. Форум к тулбарам отношения иметь не должен. Форум — это ОО-модель данных. А тулбар представитель ГУИ. И мешать их не нужно.
VD>>Диалог нового сообщения является частью гуи фичи. А гуи — это как раз задача контрола.
AVK>>Не надо выдумывать того чего нет.
VD>Такое ощущение, что ты сам с собой разговариваешь.
AVK>> Задача контрола — показать данные и позволить управлять ими.
VD>Контрол наш, мы ему задачи и будем ставить.
AVK>> Иначе у тебя окажется что в контрол надо воткнуть вобще все что в янусе есть, потому что там практически один гуй.
VD>Не окажется. Каждая фича имеет свой гуи. Ну, и гуи может иметь свою ОО. Вот только к данным она не относится.
AVK>> Окошко для ввода нового сообщения абсолютно независимая от контрола штука, спокойно работает без него и никоим образом в нем не нуждается ни для создлания ни для работы.
VD>Контрол отвечает за весь ГУИ фичи. Так что если окно имеет отношение к ГУИ фичи, значит она имеет отношение к этому контролу. При другой активной фиче форум на задан, и стало быть данная функция (а окно это не более чем функция) не получит полного списка аргументов.
AVK>> Оно работает напрямую с БД, а в перспективе наверное с объектной моделью. С какой стати оно должно подчиняться форуму мне не понятно.
VD>Да с такой. Если фичи будут независимы, то все действия будут отноститься к ним. При активном поиске создание нового сообщения вявляется довольно маразматической ситуацией. А кнопка поиска глупостью в форуме. Еще раз могу повторить, что это окно есть ни что иное как часть ГУИ фичи. Вернее одна из функций этого гуи.
AVK>>А почему не outbox, из него ведь его тоже можно вызвать?
VD>В outbox-е попросту не будет понятия активного форума. А без этого понятия создать сообщение невозможно (ответ подавно). Если же в самой форме можно выбрать форум и окно не привязано к форуму, то это уже ГИУ всего приложения и к фичи оно отношение не имеет. Тогда его просто нужно вынести в глобальное меню. Причем это справедлив даже если сама фича будет отдавать меню и обрабатывать его команды. Так, что это очередное притягивание за уши. Я же говорю, о том, что негоже совмещать модель данных и их ГУИ.
VD>А контекстные меню и тулбар (о которых и идет речь) являются частью ГУИ фичи. Ну, а гуи фичи инкапсулирован в контроле.
VD>Фича является частью ОО-модели. Она не должна иметь тесной связи с ГУИ. Чем меньше связь между фичей и ГУИ, тем проще будет развивать приложение.
VD>>Если мы хотим сделать хоум универсальным, нужно стараться не интегрировать гуи фич и код формы.
AVK>>Ну так о том и речь. Вот только меню и тулбар это не код формы совершенно, а совершенно отдельный функционал, стоящий наравне с контролом фичи.
VD>Меню и тублары это ГУИ. Им не место в ОО-данных.
AVK>>Даже визуально они вполне равноправны и никоим образом не подчинены один другому.
VD>Не даже, только. Толко визально они стоят отдельно и равноправны. Реально же они подченены логике ГУИ, которая... ну ты дагадался.
VD>>Сам по себе ответ конечно желательно было бы оформить в виде метода у Msg. Но гуи к нему это уже другой вопрос.
AVK>>Кто бы спорил. Я только не пойму почему гуй это обязательно контрол.
VD>ГУИ — это не только контрол. Я просто инкапсулировал связь с ГУИ для фичи в виде одной ссылки. Именно, чтобы не свызывать ОО-модель данных и ОО-модель гуи. ОО-модель ГУИ мы вообще толком не обдумывали. Сейчас ведется только переползание на хотя бы каую-нибудь ОО-моедь. У нас пока даже ОО-модель данных до конца не создана. Так нет модели аутбокса и поска. А так же большинство изменений БД делаются в обход ОО-модели. Короче, работать еще есть над чем. Но вот если мы будем сваливать в кучу ГУИ и ОО-модель, то получим задницу.
AVK>> Ты же сам себе противоречишь. Хочешь чтобы контрол был как можно сильнее отвязан от специфики фич, но тем не менее зачем то навешиваешь на него лишний функционал.
VD>Осталось доказать, что функции лишнии и то, что я что-то навязываю. Тога на этот вопрос можно будет ответить.
AVK>>А чем собственно меню в этом плане отличается от контрола?
VD>Тем, что меню не является полноценным объектом. Меню это всего лишь вью (в любимой тобой MVC) и ему требуется код обрабатывающий события. И этот код очень гармонично ложится в контрол. Таким образом в терминах тай же MVC контрол яляется одновременно вью (так как содержит контролы) и контроллером (так как содерижит обработчики и логику ГУИ), а меню попросту не полноценно. И нет никаких причин чтобы контрол не мог бы стать контроллером для меню и тулбара. А вот фича тут быть контроллером не должна. Ну, а тупо перекладывать ссылки на меню из контрола — бессмысленно.
AVK>>Не хочешь помещать код создания меню в фичу? Ну тогда можно создать отдельный класс, который будет этим заниматься.
VD>Я тебя удевлю. Такой класс уже создан. Это и есть контрол. Естественно в самом абстактном виде. Почему? Да потому, что контрол нужен в 99%-ов случаев. Кстати схема должна работать и без контрола. Можно даже сделать так, чтобы перед работой с ним как с контролом проверялоь является ли он контролом и если нет, не работать.
AVK>> Хотя сейчасO создание меню или тулбара это ровно одна строчка.
VD>Это к делу не относится.
AVK>>Вот только зачем перегружать фунциональностю контрол, который уже сейчас черезмерно сложен?
VD>Т.е. зачем класть код обработки ГУИ в контрол, а не в модель данных? Ну, я верю, что на этот вопрос ты способен ответить и сам!
VD>>Каждая фича будет иметь свою ОО-модель, в то время как сами фичи универсальны. AVK>>А чем контрол в этом плане выгодным образом отличается от меню? ИМХО ничем.
VD>Тем, что он и является инкасулюцией ГУИ фичи. У приложения есть два варианта представления: 1) ОО-модель данных, 2) ОО-модель ГУИ. Связь между ними (а главное зависимость данных от гуи) должна быть минимальна. Тогда можно будет работать с приложением программно не натыкаясь то и дело на ГУИ. По идее все диалоги нужно оформить в виде методов. Какие-то из диалогов будут относиться к фичам, какие-то к приложению в целом. Тоже самое с тулбаром. Более того! По большому счету приложение — это тоже фича. Просто — это фича которая всегда активна причем параллельно с ней может быть активна и другая фича. Фича это тоо место где ГУИ мапится на ОО-модель данных, но из этого не следует, что в ОО-модель форума нужно пихать меню. Если хочишь сделаем еще список глобальных фич.
VD>Вообще, забавно это слышать от человека который убеждал меня недавно, что коллекция не должна быть привязанна к гриду.
VD>> Если в первом пункте еще можно было говорить об ответе на активное сообещие, то помечаться как прочитанные могут сразу несколько сообщений, а значит эта кнопка зависит от списка выделенных сообщений.
AVK>>Не любая. Те, которые помечают все сообщения или по дате никак не подвязаны. Контрол в данном случае является всего лишь дополнительным источником данных, но никак не хозяином.
VD>Перевернул все с ног на голову, перемешал все понятия... и вышла каша. Нет дополнительных и основных. Если одного из источников нет, то работать ничего не будет.
VD>Кнопка имеет отношение толко к гуи форума. А вот сама пометка сообщений как раз функция ОО-модели данных. Точнее часть функционала форума. Обрати вниманеие именно форума как объекта, а не как гуи. Вот ГУИ активируясь должен показать эту кнопку. А при нажатии на нее гуи должен взять все нужные данные и вызвать метод у ОО-модели форума. Т.е. ГУИ как бы является способом взять от пользователя неизвестные параметры для вызова метода.
VD>>Выделение не являются частью ОО-модели,
AVK>>Совершенно верно, оно является частью модели самого контрола, однако это не единственные данные, с которыми работают эти кнопки.
VD>Думаю, чтобы тебе было проще расслабиться нужно забыть про контрол и говорить только о ГУИ-модели и ОО-модели. Тогда даже не возникнет таких вопросво. Ведь глупо засовывать меню (ГУИ-компонент — думаю, не будешь спорить, что меню это гуи?) в ОО-моедель того же форума. Контрол же является всего лишь полимпорфной связью гуи и ОО-модели.
VD>>и стало быть без контрла в этой кнопке смысла нет.
AVK>>Без объектной модели впрочем тоже.
VD>Не сомненно. Но у гуи есть полный доступ к ОО-модели. Это ОО-модель нужно беречь от смешивания с ГУИ. А на оборот пожалуста. ГУИ же наоборот нужно беречь, не от ОО-модели, а от прямой работы с данными.
AVK>> Однако это же не повод пихать меню туда. Ты пойми — в этой операции конрол выступает подчиненным — у него берут данные и ему приказывают обновиться. Сам же он занимает пассивное положение.
VD>Это не важно. Ведь не ОО-модель им управляет. Им управляет так сказать ГУИ основаной фичи (само приложение). Вернее логика его гуи.
VD>В общем, выресовывается красивая схема. Есть ОО-модель данных. И есть приложение. Приложение читает ОО-модель и отображает данные для пользователя в виде дерева навигации. Далее когда пользователь выбирает фичу гуи формы получает гуи для конкретной фичи (мне вот как раз этот момент меньше всего нравится) и активирует его.
VD>Связь фичи и его гуи нужна в основном для поддержки независимого расширения приложения. Фичу можно добавить динамически и стало быть ее гуи тоже должен добавляться динамически.
AVK>>Нет, вот это как раз прямое управление контролом, а никак не сообщениями.
VD>Развивая твою логику сообщения тоже бирутся из ОО-модели.
VD>>Ну, я вроде все обяснил. Или ты не понял? К фичам меню точно не отностся. Это гуи.
AVK>>Само меню не относится, но обеспечивать его должна именно фича, поскольку именно она обеспечивает контрол, который не меньшее гуи чем меню.
VD>Попробую еще раз (хотя уже очень надоело). Связь между фичей и ее гуи должне быть минимальная. Я остановился на возвращении одного указателя. При этом внутри фича вообще не общается с ГУИ. Да у нее есть события, но сама она ничего не делает. По хорошему нужно было вобще возвращать не ссылку на класс, а идентификатор типа, а созданием гуи должно заниметься основное гуи. Но я делал все не с нуля и в приложении уже нехилвые завязки на экземпляры контролов. Пришлось делать именно так. И по-моему — это самое оптимальное решение на сегодня.
AVK>>Ты так и не объяснил почему контрол в этом отношении особенный.
VD>Пытался. Но это как в случае с сервером приложений. Ты свыкся с одни взглядом и не хочешь принимать другой. Я уже несколько раз говорил, что контрол выбран потому, что он фигурирует наиболее часто и именно в нем лежит основной код. По большому счету это должен быть не контрол, а ОО-моделб ГУИ фичи. Так понятно?
VD>>Могу попробывать по другому. Фича — это возможность хоума. Она активируется и работа ведется с ней. После активации весь гуи это уже отдельная песня. Фича же полиморфная структура. Нефига на нее цеплять, то о чем ей и знать не интересно.
AVK>>А зачем ты нацепил на нее контрол в таком разе?
VD>Связь между фичей и гуи все же нужна. Но я старался сделать ее как можно меньшей. Одна ссылка — это том минимум который мне кажется оправдан.
VD>>Обработка меню и тулбаров прераготива контрола.
AVK>>Вот собственно почему это так ты все еще не объяснил.
VD>Да потому, что он ГУИ, и меню ГУИ. Меню это часть гуи!
AVK>>Это сейчас они его часть. Это ненормально. Представь что у тебя есть MDI приложение, внутри главного окна есть меню и тулбар, а так же подчиненные окна. Следуя твоей логике код тулбара и меню должен быть в компоненте подчиненной формы.
VD>Передергивание не даст тебе ничего полезного. Я тебе уже говорил, что ГУИ фичи должен возвращать только те меню которые относятся именно к нему. Если меню глобальное, то нефига его вообще цеплять к фиче. Это просто ошибка.
AVK>>Ну тогда отделяй от нее еще и контрол, оно такое же гуи.
VD>Если бы можно было обеспечить связь между фичей и гуи как-то по другому, я бы это сделал. Похоже тебя заело именно то что я вябрал контрол в качестве базового указатлея. Ну, попробуй воспринимать его как некий пустой интерфейс. Я хочу чтобы в качестве фичи можно было подключить обычный контрол. И по этому приходится возвращать именно контрол, а не обжект или абстрактный интерфейс.
VD>>Он не важнее. Он "определяет весь гуи". AVK>>Почему? Вот этого я никак и не могу уловить.
VD>Потому, что так сделано. Меню без контрола быть не может. Тулбара тоже. А вот контрол без них спокойно. Потому и контрол.
AVK>>>А ты подумай о том что контрол может быть один и тот же, а меню и тулбары разные. VD>>Это проблемы контрола. AVK>>Ты же агитировал за возможность максимально упростить контрол.
VD>Будут ему нужны тублары возвратит их. Не будут не возвратит. Все равно без контрола некому будет обработать эти самые нажатия на кнопки.
VD>>Его внутренняя логика.
AVK>>Слушай, ты прямо как не читал то что я писал. Часть воздействий из меню вобще никакого отношения к контролу не имеет.
VD>Все воздействия из меню этого контрола имеют отношения к этому контролу. Если это не так, то ты просто не верно засунул пункт меню. Контрол — это ГУИ фичи. Если фича не активна, то и тубларов видно не будет. Не важно что для обработки нажатия не нужно брать данные из контрола. Он — это сердце гуи. В нем вся обработка. И поэтому он экспортирует меню, а не фича. Фича не имеет права иметь внутри себя гуи. А возвращать просто ссылку на черт занет что бессмысленно.
AVK>> С ними как? Представим что их нет? Желание избавится от лишней функциональности в фиче еще не означает что контрол нужно превращать в монстра. ForumDummyForm.cs больше 70К и это уже явная порнография.
VD>Это демагоги. 70К — не проблема. Если реализовать все как следует убрав логику данных из этого файла, он даже похудеет. У нас все файлы измеряются десятками килобайт, ну и что? Совершенно нормально, что главная фича занимает много места. Вот очент странно, что SearchDummyForm.cs занимает 87. Это же только поиск.
AVK>>>Вспомни лучше MVC. Контрол это View, отчасти Controller. Зачем ты еще пытаешься навесить на него функции Model мне непонятно.
VD>>Ты снова пытаешся приплетать шаблоные VD>>вместо того чтобы думать.
AVK>>Ты вобще отдаешь себе отчет в том что ты абсолютно без оснований грубо на меня наехал?
VD>Это не так. Я тбе сказал, что что есть. Ты пытаешся применить шаблон MVC к ситуации которая сложенее его. Я тебе уже не раз говорил, что бездумное применение этих шаблонов ведет к бессмыслице.
AVK>>Давай все таки проявлять взаимное уважение, я все таки тебя не оскорбляю. Я уж не говорю о том что ты опять начинаешь переходить на личности.
VD>Извини, если я тебя обидел. Я не хотел. А про личности ты давай заканчивай. Я возражаю против некоректного использования патернов проектирования. И про тебя лично я ничего не говорил. Ты как-то не верно толкуешь термин "переход на личность".
VD>>В терминах твоего MVC AVK>>Он не мой, и не надо пытаться меня оскорбить. Давай все таки придерживаться фактов а не эмоций.
VD>Я тебя не оскорбляю, но ты пытаешся всунуть в более сложную модель более простую.
VD>>контрол это и вью и контролер в одном флаконе. Да и моедль, если вести речь о ОО-модели ГУИ. В жизни все сложенее. И примитивные концепции можно использовать только на элементарных ее частях.
AVK>>И что из этого всего следует? То что всю логику надо запихнуть в контрол?
VD>Всю ГУИ-логику связанную с конкретной фичей.
AVK>>Ты совершенно прав, говоря о то что у контрола есть своя модель.
VD>Спасибо за признание!
AVK>> Дело в том что структура хорошо спроектированного приложения как правило фрактальна.
VD>У. Тебя потянуло на философию... Молчу, молчу. А то ты меня снова будешь обвинять в оскорблении твоей личности.
AVK>> Нижний уровень это классы, поля класса это модель, интерфейс — вью, а методы контроллер.
VD>А. Я то думал. Ну, тогда все впорядке. В шарпе все кроме примитивов — это VMC. А раз так то давай не будем обсуждать такую примитивщину.
AVK>>Теперь давай посмотрим на фичу. Модель это безусловно те данные, для работы с которыми фича предназначена. В случае форумов это собственно объектная их модель. Вьюхой вроде бы как является контрол. А где котроллер?
VD>В твоей терминалогии контрол является и контроллером и моделью одновременно. Блее того в нем их множество. Короче, видимо я плохо выразился. Нля представления данной модели шаблон MVC бессмысленнен, так как или привот к абстракции ОО-модель/ГУИ/ГУИ-код или спускается до отдельной кнопки.
AVK>> Вот тут то и оказывается каша, контроллер у нас уполз на более низкий уровень иерархии к контролу.
VD>Никакой иерархии нет. Ты это сам придумал.
AVK>> Получается что этот уровень иерархии незаполнен, а более низкий уровень контрола перегружен.
VD>Отброся неимеющиеся уровни и применя твою же аналогию могу сказать так: контрол это контролер и спаривать его с моделью не следует.
AVK>> Т.е нормальным дизайном было бы создание того чего у нас просто нет — контроллера.
VD>1. То что было вообще дизайном развать нельзя. VD>2. Обвинение данного дизайна необоснованны. VD>3. Ты похоже очень странно предсталяешь себе расшифровку этого самого MVC в применении этого шаблона к данной модели.
VD>Попрбую в тоих терминах.
VD>Модель — тут ты угодал. Модль можно сопоставить с ОО-моделью данных. Видимо догадался по названию. VD>Вью — тут ты промазал. Вью это весь гуи с точки зрения пользователя, т.е. это и меню, и тулбар, и другие контролы коих море. Кстати, грид тоже часть вью. VD>Котроллер — это код связующий ОО-модель и перечисленные мной контролы.
VD>Проблема в том, что такое представление ничего не дает. И данная моедль (MVC) тут является всего лишь безполезным знанием, так как все намного сложнее чем можно описаь этой моделью. Говорить же, что интерфейс класса — это влью вообще не кооррекно. Вообще аналоги между MVC и классом быть не может. Класс не визульная сущьность, а MVC шаблон рассчитанных на представление УИ.
AVK>> Вариантов этого много — можно создать отдельный класс, можно нагрузить его функциоанльностью фичу. Теперь куда же нам девать менюхи и тулбары? Как ты правильно заметил, на уровне фичи это безусловно вью. Но вот работают то они не с моделью контрола, а с моделью фичи,
VD>Ошибаешся. Работает он с моделью данных (фича только часть этой модели) по средсвам кода который и является в твоей терминологии контроллером.
AVK>> то есть на одном уровне иерархии с контролом. Правда действительно часть меню работает именно с внутренней моделью контрола. То есть получается что мы пытаемся совместить принципиально два разных уровня — управление контролом и управление моделью фичи.
VD>Я то ничего не путаю. Это ты путаешь. Слава богу похоже ты заметил, что заблуждается вот только хвотил ли смелости в этом признаться.
VD>А вот ты заблуждаешся. Мнею не работает с моделью контрола. Меню это контрол дающий сигнал (так вроде в MVC события называют?) конроллеру реализованному в коде ГУИ (лежащем в контроле) на выполнение тех или иных действий.
VD>Просто нужно понять, что тут или смесь этого самого контроллера с вью или море мелких контроллеров и вью.
VD>Что же касается неотносщихся к "контролу" пунктов меню, то или они попали не по назначению, так как не относятся к активной фиче, или они являются частью ГУИ фичи, но просто не требуют дополнительного контекста.
AVK>> ВОт здесь действительно противоречие, однако не думаю что упихивание всего в контрол является хорошей идеей.
VD>Поверь, куда более лучшей чем приметивный MVC.
AVK>> Можно наверное заставить контрол отдавать свои элементы управления, а фичу свои, можно внутри контрола создать минитулбар, объединив его с кнопками простановки оценок. В общем решений может быть много.
VD>Заставляя фичу отдавать элементы управления ты будешь вынужден слить обработку событий от них с логикой данных. Или перенаправлять эти события во вне (например, тому же контролу). Кривойсть этого была прекрасно видна после твоих переделок. Ведь если следовать твоей логике контол не имеет права обрабатывать события от мню, а у тебя было именно так. Если попытаться избавиться от этого, то получится, что события должена будет обрабатывать фича, но она же редставление модели данных! И это прямое нарушение той же модели MCV (ничего, что я ею спекулирую ? ).
VD>Если же посмотреть под углом той же MVC, но подругому, можно заметить, что фича будет моделью данных, а контроллеры и влью будут переплетены в контрле. Причем не важно, что это контрол. Важно, что это код ГУИ отделенный от данных. Ну, а связь между ГУИ и фичей ни что иное, как некая мета-связь позволяющая подгружать ГУИ для фичи на основании типа фичи.
AVK>>А как быть к примеру с пометкой всех сообщений форума?
VD>Это тоже не сомненно часть ГУИ фичи, и так как контрол является реализацией этго гуи, он и должен контролировать эту фнкцию.
VD>Последний раз на последок. Контрол воспринимается мною как код содержащий ГУИ для отдельно взятой фичи. Только для нее! Но в то же время весь код гуи, т.е. не только то что делается визульно. При этом тулбары воспринимаются как часть этого гуи которую просто не удается запихнуть в рамки прямоугольного простарнства самого контрола. Ну, а контрол был выбран исключительно из-за универсальности. Так как минимальным ГУИ для ичи является именно контрол.
VD>Самое смешное, что у в хоуме даже не пришлось много переделывать, так как решение о запихивании ГУИ фич в контролы принял ты. Ты даже не знал о том, что это гуи для фичь, но сделал это! Так как это просто оподсказывает интуиция.
Здравствуйте, AndrewVK, Вы писали:
AVK>А вот тут ты невнимательно читаешь документацию. AVK>
AVK>Pointer to a RECT structure that specifies the rectangle to which the rebar control should be sized.
А ты попобуй.
VD>То что ребары можно помещать на нужные места — это 100%. И IE, и OE используют именно ребоары и прекрасно запоминают позицию.
AVK>Вопрос в том как они это делают. Точнее IE 6 вобще не позволяет таскать тулбары, а вот OE действительно запоминает позицию.
Про IE 6 ты ошибаешся. Вот только, что выключил лок и перетащил линки рядом с основной панелью. После переоткрытия они были на месте.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
И пробовать нечего. Все оказалось совсем иначе.
AVK>>Вопрос в том как они это делают. Точнее IE 6 вобще не позволяет таскать тулбары, а вот OE действительно запоминает позицию.
VD>Про IE 6 ты ошибаешся. Вот только, что выключил лок и перетащил линки рядом с основной панелью.
Здравствуйте, VladD2, Вы писали:
AVK>>И пробовать нечего.
VD>Забавная аргументацяи.
Ну я все таки не верю что в документации могут так нагло врать.
AVK>> Все оказалось совсем иначе.
VD>Как?
В общем позиция бенда управляется его индексом, свойством break и размером предыдущего бенда. Т.е. при перетаскивании на самом деле пустых промежутков, не занятых бендами, нет.
Здравствуйте, AndrewVK, Вы писали:
AVK>В общем позиция бенда управляется его индексом, свойством break и размером предыдущего бенда. Т.е. при перетаскивании на самом деле пустых промежутков, не занятых бендами, нет.
Я почти уверен, что RB_SIZETORECT установит все эти параметры за один шаг.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
VD>Я почти уверен, что RB_SIZETORECT установит все эти параметры за один шаг.
AVK>А я уверен что нет. Еще раз настоятельно советую прочитать внимательнее документацию.
Читал я документацию. И ничего опровергающее не нашел. Ты бы все же попробовал. Так как описанными тобой методами рельное положение бэнда задать нельзя.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Attempts to find the best layout of the bands for the given rectangle.
Syntax
To send this message, call the SendMessage function as follows.
lResult = SendMessage( // returns LRESULT in lResult (HWND) hWndControl, // handle to destination control (UINT) RB_SIZETORECT, // message ID (WPARAM) wParam, // = 0; not used, must be zero (LPARAM) lParam // = (LPARAM) (LPRECT) prc; );
Parameters
wParam
Must be zero.
prc
Pointer to a RECT structure that specifies the rectangle to which the rebar control should be sized.
Return Value
Returns nonzero if a layout change occurred, or zero otherwise.
Remarks
The rebar bands will be arranged and wrapped as necessary to fit the rectangle. Bands that have the RBBS_VARIABLEHEIGHT style will be resized as evenly as possible to fit the rectangle. The height of a horizontal rebar or the width of a vertical rebar may change, depending on the new layout.
Если не доверяешь тексту, обрати внимание что в параметрах индекс бенда отсутствует.
VD> Ты бы все же попробовал.
Зачем?
VD> Так как описанными тобой методами рельное положение бэнда задать нельзя.
Можно. Только так и можно. Это я как раз попробовал.
. 
Видимо придется свой писать.
Да. Убедил КОМ — это никуда не годится. Там уроды все писали. Они же безграмотные. То ли дело профы из Дельфи! Хотя и туда интерфейсов по напихили.
Я же говорю, о том, что негоже совмещать модель данных и их ГУИ. 
Естественно в самом абстактном виде. Почему? Да потому, что контрол нужен в 99%-ов случаев. Кстати схема должна работать и без контрола. Можно даже сделать так, чтобы перед работой с ним как с контролом проверялоь является ли он контролом и если нет, не работать.
