Изменение внешнего вида программы.

[KBAC]

Есть объект класса конфиг, который хранится на форме. Форма - это просто контейнер для более красивого Юзер-Контрола.
Если меняются настройки программы через диалог, то изменения сохраняются в конфиге и затем нужно обновить внутренний контрол.
Как это лучше сделать?
Сейчас класс конфиг умеет изменять стиль членов класса юзер-контрола, которые являются общедоступными (public), т.е. у конфига есть методы, в которые передаются параметрами нужные члены. Этот вариант мне не нравится.
Можно сделать паблик методы у внутреннего контрола - в принципе нормально, но, думаю, что сам класс не должен заниматься своим стилем, он и так уже большой слишком. Конечно для красоты можно и в отдельный файл вынести определения методов, которые будут заниматься гуи.
Мне интересно, нет ли какого-либо шаблона проектирования для подобного случая?

[RXL]

По моему очень сумбурно. Повествование класса «можно грабить корованы». То «форма», то «контейнер», то «диалог»...
Зачем так глубоко интегрировать конфиг и контрол их друг в друга? Что это вообще за «конфиг»? Попробуй объяснить еще раз.

[KBAC]

RXL, есть форма, которая содержит в себе UserControl. В этом UserControl'e В свою очередь какие-то панели (допустим только они). И, допустим, есть необходимость в такой организации вложенности (Панель на Контроле, Контрол на Форме). Внешний вид панелей меняется в зависимости от выбранного стиля.
Буду называть ЮзерКонтрол просто Контролом.
Через пункт меню на форме можно вызвать Форму с настройками внешнего вида. Какие-то настройки поменяли - изменили стиль внешнего вида Контрола подразумевается; нажали кнопку ОК. Настройки сохранились (Это обеспечивает класс Конфиг). Теперь надо применить настройки к Контролу.
Про методы класса Конфиг, которые меняют стиль, думаю, понятно (если нет могу попробовать еще раз объяснить).
Вопрос в том, как лучше сделать изменение внешнего вида Контрола (применение стиля оформления), если информация о выбранном стиле хранится в Конфиге, который в свою очередь является членом формы наравне с Контролом?

[RXL]

UserControl::applySettings(Config config);

Чем не устраивает?

[KBAC]

Класс большой слишком, не хочу его усложнять методами визуализации.

[zubr]

Сделай пользовательское сообщение у юзер-контрола, а из конфига посылай юзерконтролу это сообщение с указателем на память, где хранятся данные по стилю.

[Dimka]

По-моему автор не вполне понимает, чего он хочет.

Есть описание (конфигурация) и отображение (контрол). Описание может меняться, как оно меняется, кто его меняет, это не волнует ни само описание, ни отображение. Но вот когда изменения закончились, отображения должно их воспринять.

Таким образом, из триады MVC конфигурация играет роль модели (Model), а контрол - представления (View). Ну и риторический вопрос, как представлению следить за обновлением модели.

Тут есть 2 подхода:

1) Пассивная модель. В этом случае изменением модели занимается только контроллер, и поэтому он инициирует обновления представления (посылает ему соответствующее сообщение, в ответ на которое представление опрашивает модель и осуществляет необходимые изобразительные действия на экране).

2) Активная модель. В этом случае модель может меняться несколькими контроллерами, которые друг о друге и о представлении могут ничего не знать, а связь модели и представления реализуется посредством шаблона проектирования "Наблюдатель" (Observer). Для .NET это банально описать событие (event) внутри модели, и подписать на него обработчик внутри представления.

Ну и вот - выбрать схему и реализовать.

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

[KBAC]

zubr, ты под сообщением имеешь ввиду событие? Если так, тогда не понятно, почему событие должно быть инициировано в контроле, а посылать его должен конфиг.
Dimka, т.е. ты предлагаешь организовать метод вида UserControl::applySettings(Config config), который будет вызываться по событию? В общем виде это выглядит так, как я понимаю.

[zubr]

KBAC, по моему логично. Изменения в конфиге уведомляют контрол, что ему нужно обновиться.

[Джон]

KBAC, а откуда Контрол получает изначально данные о своей конфигурации? Неужели не из Конфига?

[KBAC]

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

Добавлено через 34 минуты и 24 секунды:
Вот только одна проблема нарисовалась. Совсем забыл, что это разные проекты. В проекте, где я хочу отрисовывать, обнаруживается, что нет необходимых типов.

[Джон]

Джон, Из конфига, но все тем же нехорошим способом, при котором необходимо открывать элементы ГУИ моего контрола для внешних объектов.

С этого места поподробнее. Я не могу себе представить, что некий элемент, требующий для своей отрисовки, например, цвет, дожен быть public, чтобы этот цвет получить. Открытый Конфиг я ещё где-то могу понять, но открытый GUI...

Добавлено через 1 минуту и 13 секунд:

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

А интерфейс не пробовал использовать?

[KBAC]

Джон, у меня есть некоторое перечисление, по которому я определяю как мне отрисовать мою панельку. Область видимости перечисления - весь проект Browser.
Мой Контрол реализован в проекте Control и там необходимое перечисление не видно. Создавать клон перечисления - бред. Вот и решил вытащить наружу панельку, стиль которой и задаю в проекте Browser (т.е. там меняю ее image).
В общем, сделал, чтобы в Browser'e анализировались значения Config'a и принималось решение, какой image передавать в функцию UserControl::ApplyStyle(Image image), а UserControl уже дальше применяет это изображение  к своей панельке.
В принципе меня все устраивает, наверное лучше и не придумаешь в данной ситуации.

А интерфейс не пробовал использовать?

Это как?

[Джон]

Ничего не понял. Перечисления... проекты... области видимости... Контрол есть сама по себе завершённая самодостаточная единица. Вот берёшь ты, к примеру, какой-нить grid, кидаешь его на форму и никаких тебе проектов и пр. А есть готовый объект со всеми свойствами, ф-ми и отрисовкой.

С интерфейсом делается так. Создаёшь абстрактный класс с набором ф-ций или свойств (как тебе удобней), которые отвечают за конфигурационные данные, и передаёшь его в свой контрол. Для визуального редактора отлавливаешь null этого объекта и используешь дефолтные параметры. Во всех остальных случаях передаёшь в контрол объекты, включающие этот интерфейс и обеспечивающие поставку необходимых данных. Кстати, очень удобно для тестов.

[Dimka]

Если перечисление описывает внешний вид Control, то оно должно находиться в одной сборке с ним, а не в другой (Browser).

P.S. Неужели всё это нагромождение с конфигами ради enum?.. 

[KBAC]

Dimka, enum используется также для применения стиля и к элементам Browser'a. Т.е. первостепенно, это свойство браузера, все таки.
Отвечая на твой вопрос понял следущую вещь: Контрол теперь (благодаря моему решению) можно использовать как плагин для разных браузеров, у которых может быть свой внешний вид, и под который Контрол должен будет подстроиться.

Неужели всё это нагромождение с конфигами ради enum?..

Ну там еще другие настройки есть помимо стиля