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

VD>Зачем? Сделай отдельное свойство "Цветовая схема". Или отдельную закладку. На ней выдавай список схем (из хмл-ных файлов) и просто коприуй значения из выбранной в конфиг. Просто, удобно и всегда можно зименить одно значение не меняя всей схемы.

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

Настройка стиля у контролов — по желанию. Либо через менеджер, лиюо ручками из StyleConfig-а.

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

VD>Да не нужен никакой менеджер. Есть только цвет фона и текста. Которые прекрасно можно установить на основную форму. Остальные съедят его автоматом. А цвета вроде цвета подсветки ответов один фиг из конфига читать.

VD>И вообще схема на собятиях будет надежнее обхода. Ведь если свойство не стандартное, то твой обход обламается.

В общем, я к такому выводу и пришел .


Можно перекрыть Control.Refresh и в нем заново перечитывать цвета из конфига при обновлении. И соответственно, подписаться на изменение стиля. Правда, контролу придется отписываться в Dispose или еще где, или делать свои event-ы на слабых ссылках.

Основан на StyleConfig — синглтон конфига (как и Config.cs)

1. Config.cs содержит свойство StyleConfig, которое ссылается на синглтон StyleConfig-а, т.е текущая схема таким образом автоматически сохраняется внутри Config-а.

2. StyleConfig содержит статическое событие, которое запускается, если было изменено какое-то свойство (т.е подписанные контролы обновляются сразу при изменении какого-либо свойства).

3. Контролы могут подписываться где-нибудь в конструкторе, отписываться в Dispose.

4. StyleConfig может быть сохранен/загружен отдельно от Config-а — внешние схемы.

Что мне с этим теперь делать?

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

VD>>Собственно это от тебя и росли. Если бы ты не вредничал, давно уже были бы настраиваемые цвета.
AVK>>Я думал что тебе не надо элементарные вещи объяснять.

VD>Я с этим еще рне возлся. Дернулся... не вышло... дернул тебя... ты полез вредничать.

Но вот WFrag почему то моих объяснений хватило.

VD>В общем это притягивание за уши.

Извини, но я подобное уже делал, а ты нет. И твои неаргументированные утверждения меня не убедили.

VD> Ты лучше скажи что ты будешь делать когда пользователь захочет изменить один цвет? Заставишь его фйл править или будешь ще один редактор конфигов делать?

Сделаю еще один PropertyGrid. Там даже писать ничего не надо, просто на форму кинуть.

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

VD>И в чем он? Пробежаться и отобрать свойства одного типа?

А ты посмотри код.

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

WF>Можно перекрыть Control.Refresh и в нем заново перечитывать цвета из конфига при обновлении. И соответственно, подписаться на изменение стиля. Правда, контролу придется отписываться в Dispose или еще где, или делать свои event-ы на слабых ссылках.

Зачем. Блокироваться будет тот, на чьи события подписались. В твоем же случае контрол наоборот сам подписывается. Так что не надо никаких слабых ссылок.

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

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

WF>>Можно перекрыть Control.Refresh и в нем заново перечитывать цвета из конфига при обновлении. И соответственно, подписаться на изменение стиля. Правда, контролу придется отписываться в Dispose или еще где, или делать свои event-ы на слабых ссылках.

AVK>Зачем. Блокироваться будет тот, на чьи события подписались. В твоем же случае контрол наоборот сам подписывается. Так что не надо никаких слабых ссылок.

А если контрол не отпишется? Он сможет своей смертью помереть?

Хотя по-любому, это паранойа .

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

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

WF>Ну можно просто в конфиг вставит свойство StyleConfig. При этом конфиг будет содержать текущую настройку стиля полностью в своем файле. При загрузке пресет XmlSerializer-ом поднимать StyleConfig и вставлять его в конфиг, при сохранении сбрасывать. Далее, сделать отдельную закладку, на нее PropertyGrid, ему скормить StyleConfig.

Вложенным классом сделать цвета конечно можно. А зачем его "При загрузке пресет поднимать" и т.д.? Пускай в конфиг и сериализуется.

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

AVK>Но вот WFrag почему то моих объяснений хватило.

Значит он знал больше. Собственно у него я и увидил то что было нужно (атрибут заперщающий сериализацию)

VD>В общем это притягивание за уши.

AVK>Извини, но я подобное уже делал, а ты нет. И твои неаргументированные утверждения меня не убедили.

Не аргументированные утверждения именно твои. Я уже сказал, что второй конфиг — это зло. И нужо иметь возможность настраивать каждый цвет отдельно. Это все означает, что данные нужно хранить именно в конфиге.

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

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

WF>1. Config.cs содержит свойство StyleConfig, которое ссылается на синглтон StyleConfig-а, т.е текущая схема таким образом автоматически сохраняется внутри Config-а.

Значит можно будет менять отдельные поля? Это хорошо.

WF>2. StyleConfig содержит статическое событие, которое запускается, если было изменено какое-то свойство (т.е подписанные контролы обновляются сразу при изменении какого-либо свойства).

Сразу не надо. Надо только после нажатия ОК в диалоге настройки.

WF>3. Контролы могут подписываться где-нибудь в конструкторе, отписываться в Dispose.

На есть событие изменение конфига можно на него все и изменять.

WF>4. StyleConfig может быть сохранен/загружен отдельно от Config-а — внешние схемы.

Нужен или диалог или закладку для выбора темы/стиля.

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

WF>В общем, у меня уже есть прикрученная к Янусу базовая настройка цветов. Может ее стоит залить, тогда мне доступ в CVS нужен .

Не, ты для начала распиши что ты там нагородил.

Здравствуйте, VladD2, Вы писали:
AVK>>Извини, но я подобное уже делал, а ты нет. И твои неаргументированные утверждения меня не убедили.

VD>Не аргументированные утверждения именно твои.

Ну да конечно. То что я расписал по пунктам лишнюю работу это все не аргументы. А вот то что ты сказал что это все фигня это конечно аргумент.

VD>Я уже сказал, что второй конфиг — это зло.

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

VD>И нужо иметь возможность настраивать каждый цвет отдельно. Это все означает, что данные нужно хранить именно в конфиге.

Текущие цвета несомненно. А вот все схемы там хранить не стоит.

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

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

WF>>1. Config.cs содержит свойство StyleConfig, которое ссылается на синглтон StyleConfig-а, т.е текущая схема таким образом автоматически сохраняется внутри Config-а.

VD>Значит можно будет менять отдельные поля? Это хорошо.

Не понял .

WF>>2. StyleConfig содержит статическое событие, которое запускается, если было изменено какое-то свойство (т.е подписанные контролы обновляются сразу при изменении какого-либо свойства).

VD>Сразу не надо. Надо только после нажатия ОК в диалоге настройки.

А почему? Довольно удобно . Сразу видно все изменения. Хотя, как будет на тормозных машинах, не знаю.

WF>>3. Контролы могут подписываться где-нибудь в конструкторе, отписываться в Dispose.

VD>На есть событие изменение конфига можно на него все и изменять.

Ну можно и так, если убрать пункт выше, т.е менять только после OK.

Все, что нашел, связанное с изменением конфига — в MainForm
Features.Instance.ConfigChanged(); // <- Это все и обновляет? Все формы/контролы?

WF>>4. StyleConfig может быть сохранен/загружен отдельно от Config-а — внешние схемы.

VD>Нужен или диалог или закладку для выбора темы/стиля.

Пока есть две кнопки — загрузить и сохранить пресет на новой закладке (на которой все настройки), обычные файловые диалоги. Грузят XmlSerializer-ом StyleConfig и ставят его.

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

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

WF>>В общем, у меня уже есть прикрученная к Янусу базовая настройка цветов. Может ее стоит залить, тогда мне доступ в CVS нужен .

AVK>Не, ты для начала распиши что ты там нагородил.

1. Добавлен StyleConfig.cs — по типу Config-а.
Содержит статическое свойство, которое запускается при изменении какой-либо из настроек. В принципе, можно в событии указывать, какое именно свойство было изменено, чтобы все контролы не перерисовывались.

2. Config.cs

Добавлено, для сериализации текущей цветовой схему внутрь Config.cs:

/// <summary>
/// Текущий стиль. Просто ссылка на синглтон, для сериализации внутрь конфига.
/// </summary>
public StyleConfig StyleConfig
{
    get
    {
        return StyleConfig.Instance;
    }
    set
    {
        StyleConfig.NewStyleConfig( value );
    }
}

3. У парочки подопытных контролов (ForumDummyForm, MainForm) сделана подписка на изменение стиля и сбор настроек стиля из StyleConfig-а. В Msg.cs, Forum.cs добавлено взятие цветов из StyleConfig-а.

4. Добавлена закладка в OptionsForm.
При открытии OptionsForm текущая настройка стиля сохраняется, а все изменения (PropertyGrid-ом) идут сразу в синглтон StyleConfig-а, при этом тот рассылает сообщение о измене настроек стиля.
Также на этой закладке — две кнопки, загрузить/сохранить пресет. Пока просто тупо спрашивают файл и сериализуют туда/десериализуют оттуда StyleConfig.

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

Правда, там есть баг:
Если обратиться к StyleConfig.Instance, а StyleConfig и Config еще не загружены — то создастся схема по умолчанию.
Если же обратиться через Config.Instance.StyleConfig — то сначала загрузится Config, он загрузит в процессе StyleConfig и , соответственно, будут схемы из конфига.

Можно сделать, чтобы StyleConfig.Instance форсировало pfuhepre rjyabuf (вызовом Config.Instance). Но это как-то некузяво.

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

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

AVK>>Но вот WFrag почему то моих объяснений хватило.

VD>Значит он знал больше. Собственно у него я и увидил то что было нужно (атрибут заперщающий сериализацию)

Ради справедливости замечу, что мне хватило объяснения "было на РСДН".

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

AVK>Текущие цвета несомненно. А вот все схемы там хранить не стоит.

Т.е. будет два конфига. Один обычный другой для цветов? Очень грмотно. Ооочень.

И особо радует безапеляционность: "Текущая настройка будет внутри конфига".

В общем, идея плохая. Более менее приемлемо то что в последний раз предложил WFrag:

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

WF>>1. Config.cs содержит свойство StyleConfig, которое ссылается на синглтон StyleConfig-а, т.е текущая схема таким образом автоматически сохраняется внутри Config-а.

VD>Значит можно будет менять отдельные поля? Это хорошо.

WF>Не понял .

Ну, можно будет заменить один цвет, а не всю схему?

VD>Сразу не надо. Надо только после нажатия ОК в диалоге настройки.
WF>А почему? Довольно удобно . Сразу видно все изменения. Хотя, как будет на тормозных машинах, не знаю.

Это вообще не верно. Зачем тогда вообще ОК нужен? Ну, и главно нельзя будет откатить изменения.

WF>Ну можно и так, если убрать пункт выше, т.е менять только после OK.

Только так и нужно. Или тебе придется еще анду-буфер делать. А потом все это объяснять пользователям у которых уже сложились понятия о том как работают диалоги.

WF>Все, что нашел, связанное с изменением конфига — в MainForm
WF>Features.Instance.ConfigChanged(); // <- Это все и обновляет? Все формы/контролы?

Почти, но не совсем. Это оповещение фич об изменении. Вот код вызывающий диалог настроек:

        [MethodShortcut(Shortcut.None, "Настройка приложения", 
             "Настройка приложения.")]
        public void Options()
        {
            using(OptionsForm of = new OptionsForm())
            {
                of.Owner = this;
                DialogResult res = of.ShowDialog(this);
                if((of.Action & ChangeAction.Refresh) == ChangeAction.Refresh
                    && res == DialogResult.OK)
                {
                    Features.Instance.ConfigChanged();
                  _tgNavTree.Update();
                }
                if((of.Action & ChangeAction.Restart) == ChangeAction.Restart
                    && res == DialogResult.OK)
                    MessageBox.Show(this, "Необходимо перезапустить приложение!");
            }
        }

Вот перед вызовом Features.Instance.ConfigChanged(); и нужно вставлять апдэйт цветов.

WF>Пока есть две кнопки — загрузить и сохранить пресет на новой закладке (на которой все настройки), обычные файловые диалоги. Грузят XmlSerializer-ом StyleConfig и ставят его.

Ну, подключай к Хоуму. Будем поглядать.

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

WF>В общем, у меня уже есть прикрученная к Янусу базовая настройка цветов. Может ее стоит залить, тогда мне доступ в CVS нужен .

AVK>Не, ты для начала распиши что ты там нагородил.

Да вчем проблема. Пусть заливает. Откатить если что не долго.

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

WF>4. Добавлена закладка в OptionsForm.
WF>При открытии OptionsForm текущая настройка стиля сохраняется, а все изменения (PropertyGrid-ом) идут сразу в синглтон StyleConfig-а, при этом тот рассылает сообщение о измене настроек стиля.

Не. Так дело не пойдет. Редактировать надо копию и только по ОК применять.

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

WF>Если же обратиться через Config.Instance.StyleConfig — то сначала загрузится Config, он загрузит в процессе StyleConfig и , соответственно, будут схемы из конфига.

Так к StyleConfig и нужно через Config доступ получать. А на прямое обращение нужно как-то посылать на фиг.