Здравствуйте, WFrag, Вы писали:
AVK>>А чего хочешь?
WF>Ну... Хочу пописать что-нибудь.
Что именно? Если все равно, то смотри что тебя (других юзеров) в текущем хоуме не устраивает и предлагай варианты как это исправить. Будем обсуждать. Вот например нужно прикрутить стили (цветовые схемы, скины).
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, WFrag, Вы писали:
AVK>>>А чего хочешь?
WF>>Ну... Хочу пописать что-нибудь.
AVK>Что именно? Если все равно, то смотри что тебя (других юзеров) в текущем хоуме не устраивает и предлагай варианты как это исправить. Будем обсуждать. Вот например нужно прикрутить стили (цветовые схемы, скины).
Неплохо было бы цветовые схемы. Где-нибудь в настройках, например, еще одна закладка. Чтоб можно было загрузить/настроить/сохранить. По типу горячих клавиш, там в принципе, один в один будет.
Можно, например, как и с шоркатами — помечать Color-свойства специальным аттрибутом — что-то вроде ConfigurableColorAttribute, настраиваемый цвет.
Правда непонятно, как, например, при загрузке устанавливать все цвета? Можно просто обходить дерево контролов, искать у них Color-свойства с нужным аттрибутом, искать в карте настроек цвет и его устанавливать.
Здравствуйте, WFrag, Вы писали:
WF>Неплохо было бы цветовые схемы. Где-нибудь в настройках, например, еще одна закладка. Чтоб можно было загрузить/настроить/сохранить. По типу горячих клавиш, там в принципе, один в один будет.
Сначала нужно сериализацию для цветов сделать. У нашего сериализатора конфигов позгов не хватает чтобы сохранить цвета.
В общем, вся задача сводится к превращению цвета в строку и обратно.
WF>Можно, например, как и с шоркатами — помечать Color-свойства специальным аттрибутом — что-то вроде ConfigurableColorAttribute, настраиваемый цвет.
Да их и помечать не нужно. Они и так ЦВЕТ. Вот только таких свойств пока нет. Color не сохраняется.
WF>Правда непонятно, как, например, при загрузке устанавливать все цвета? Можно просто обходить дерево контролов, искать у них Color-свойства с нужным аттрибутом, искать в карте настроек цвет и его устанавливать.
Ничего не надо обходить. Есть такой класс Config. Это синглтон. Доступ к экземпляру Config.Instancr. Любое его публичное свойство или переменная сохраняется в хмл. Но сохранялка кривая и именно Color сохранять не умеет. Так что для начала для каждого цвета нужно завести по свойству в конфиге и создать врапер-класс для сериализации цвета в строку и обратно.
Далее везеде где есть цвета нужно встроить доступ к этим свойствам. Ну, а сохраннение и загрузка тем — это приметивный код который отбирает свойства типа ТвойВрапер и сбрасывает/загружает их значение в отдельный хмл-файл.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, WFrag, Вы писали:
WF>>Неплохо было бы цветовые схемы. Где-нибудь в настройках, например, еще одна закладка. Чтоб можно было загрузить/настроить/сохранить. По типу горячих клавиш, там в принципе, один в один будет.
VD>Сначала нужно сериализацию для цветов сделать. У нашего сериализатора конфигов позгов не хватает чтобы сохранить цвета.
Это не проблема. Поиск по РСДН-у, как и говорил АВК, дал вполне определенный результат.
VD>В общем, вся задача сводится к превращению цвета в строку и обратно.
WF>>Можно, например, как и с шоркатами — помечать Color-свойства специальным аттрибутом — что-то вроде ConfigurableColorAttribute, настраиваемый цвет.
VD>Да их и помечать не нужно. Они и так ЦВЕТ. Вот только таких свойств пока нет. Color не сохраняется.
WF>>Правда непонятно, как, например, при загрузке устанавливать все цвета? Можно просто обходить дерево контролов, искать у них Color-свойства с нужным аттрибутом, искать в карте настроек цвет и его устанавливать.
VD>Ничего не надо обходить. Есть такой класс Config. Это синглтон. Доступ к экземпляру Config.Instancr. Любое его публичное свойство или переменная сохраняется в хмл. Но сохранялка кривая и именно Color сохранять не умеет. Так что для начала для каждого цвета нужно завести по свойству в конфиге и создать врапер-класс для сериализации цвета в строку и обратно.
Я хотел другой способ. Не формы/контролы опрашивают конфиг о цветах, а специальный менеджер обходит формы/контролы и устанавливает в них экспортированные (посредством аттрибута) цвета в значение из конфига. Аттрибут также нужен для описания цвета. Например вот так (в ForumDummyForm.cs):
[ConfigurableColor( "Фон дерева сообщений" )]
public Color TreeGridBack
{
get
{
return this.treeGrid.BackColor;
}
set
{
this.treeGrid.BackColor = value;
}
}
Далее отдаем на съедение нужные формы/контролы менеджеру, он их пробегает, строит список настраиваемых цветов, и вставляет их каким-нибудь образом в PropertyGrid, например. Или куда-нибудь еще, короче, дает возможность их изменить. После изменения, менеджер пробегает по всем данным ему контртолам и вставляет цвета. Этот способ хорош тем, что:
1. Все что нужно — "экспортировать" цвет, пометив свойство аттрибутом. В контроле декларируются визуальные свойства, которые можно настраивать (можно не только цвета, а в принципе, любое визуальное свойство контрола) — и менеджер тем дает пользователю их настроить.
2. Если цвет изменился — менеджер его может просто изменить у контрола, не нужно контролу самому откуда-то доставать цвета, устанавливать их при их изменении.
VD>Далее везеде где есть цвета нужно встроить доступ к этим свойствам. Ну, а сохраннение и загрузка тем — это приметивный код который отбирает свойства типа ТвойВрапер и сбрасывает/загружает их значение в отдельный хмл-файл.
Здравствуйте, WFrag, Вы писали:
WF>Неплохо было бы цветовые схемы. Где-нибудь в настройках, например, еще одна закладка. Чтоб можно было загрузить/настроить/сохранить. По типу горячих клавиш, там в принципе, один в один будет.
WF>Можно, например, как и с шоркатами — помечать Color-свойства специальным аттрибутом — что-то вроде ConfigurableColorAttribute, настраиваемый цвет.
WF>Правда непонятно, как, например, при загрузке устанавливать все цвета? Можно просто обходить дерево контролов, искать у них Color-свойства с нужным аттрибутом, искать в карте настроек цвет и его устанавливать.
Вот только нужно не только цвета, но еще и шрифты хотя бы настраивать.
Здравствуйте, VladD2, Вы писали:
WF>>Неплохо было бы цветовые схемы. Где-нибудь в настройках, например, еще одна закладка. Чтоб можно было загрузить/настроить/сохранить. По типу горячих клавиш, там в принципе, один в один будет.
VD>Сначала нужно сериализацию для цветов сделать.
Да, проблема.
VD>У нашего сериализатора конфигов позгов не хватает чтобы сохранить цвета.
Сериализатор тут не при чем. При чем Color.
VD>В общем, вся задача сводится к превращению цвета в строку и обратно.
Эта задача уже решена, называется ColorTypeConvertor.
WF>>Правда непонятно, как, например, при загрузке устанавливать все цвета? Можно просто обходить дерево контролов, искать у них Color-свойства с нужным аттрибутом, искать в карте настроек цвет и его устанавливать.
VD>Ничего не надо обходить. Есть такой класс Config. Это синглтон. Доступ к экземпляру Config.Instancr.
Я думаю не стоит в конфиге хранить всю схему. Лучше только имя файла, а саму схему в отдельном файле, чтобы человек мог просто готовый файл скачать.
Здравствуйте, WFrag, Вы писали:
WF>Я хотел другой способ. Не формы/контролы опрашивают конфиг о цветах, а специальный менеджер обходит формы/контролы и устанавливает в них экспортированные (посредством аттрибута) цвета в значение из конфига.
Мысль конечно правильная, но не факт что реализуемая. Сейчас нет никакой формализуемой структуры связей экземпляров элементов гуя. Кто то один раз создается и по сути синглтон, кто то поднимается по запросу, кто то дергается при каждом обращении. В общем продумывать надо, так сразу трудно что то определенное сказать.
WF>Далее отдаем на съедение нужные формы/контролы менеджеру,
А кто это будет делать?
WF> он их пробегает, строит список настраиваемых цветов, и вставляет их каким-нибудь образом в PropertyGrid, например. Или куда-нибудь еще, короче, дает возможность их изменить. После изменения, менеджер пробегает по всем данным ему контртолам и вставляет цвета. Этот способ хорош тем, что: WF>1. Все что нужно — "экспортировать" цвет, пометив свойство аттрибутом. В контроле декларируются визуальные свойства, которые можно настраивать (можно не только цвета, а в принципе, любое визуальное свойство контрола) — и менеджер тем дает пользователю их настроить. WF>2. Если цвет изменился — менеджер его может просто изменить у контрола, не нужно контролу самому откуда-то доставать цвета, устанавливать их при их изменении.
Есть у него и недостатки — структура схемы в общем случае не определена. Стоит подумать о жестком описании в xml-файле набора свойств, управляемых стилизатором.
Здравствуйте, AndrewVK, Вы писали:
WF>>Я хотел другой способ. Не формы/контролы опрашивают конфиг о цветах, а специальный менеджер обходит формы/контролы и устанавливает в них экспортированные (посредством аттрибута) цвета в значение из конфига.
AVK>Мысль конечно правильная, но не факт что реализуемая. Сейчас нет никакой формализуемой структуры связей экземпляров элементов гуя. Кто то один раз создается и по сути синглтон, кто то поднимается по запросу, кто то дергается при каждом обращении. В общем продумывать надо, так сразу трудно что то определенное сказать.
WF>>Далее отдаем на съедение нужные формы/контролы менеджеру,
AVK>А кто это будет делать?
Да, с этим проблема.
Хотя, можно, например, в конструкторе контрола регистрироваться в менеджере (менеджер — синглтон). При этом, менеджер может держать слабые ссылки на зарегистрированные контролы (чтобы не продлевать их жизнь зря).
WF>> он их пробегает, строит список настраиваемых цветов, и вставляет их каким-нибудь образом в PropertyGrid, например. Или куда-нибудь еще, короче, дает возможность их изменить. После изменения, менеджер пробегает по всем данным ему контртолам и вставляет цвета. Этот способ хорош тем, что: WF>>1. Все что нужно — "экспортировать" цвет, пометив свойство аттрибутом. В контроле декларируются визуальные свойства, которые можно настраивать (можно не только цвета, а в принципе, любое визуальное свойство контрола) — и менеджер тем дает пользователю их настроить. WF>>2. Если цвет изменился — менеджер его может просто изменить у контрола, не нужно контролу самому откуда-то доставать цвета, устанавливать их при их изменении.
AVK>Есть у него и недостатки — структура схемы в общем случае не определена. Стоит подумать о жестком описании в xml-файле набора свойств, управляемых стилизатором.
Ну да, можно просто в неком xml задавать, какие вообще бывают настройки стиля, т.е описание, название(ключ), тип. А контрол просто просит у менеджера по заданным ключам элемент стиля.
Получаем два варианта (которые могут быть реализованны одновременно):
1. Контрол сам опрашивает менеджера стилей (при этом контролу следует подписаться на изменения стилей).
2. Менеджер стилей сам устанавливает требуемые свойства (при этом контрол должен быть зарегистрирован в менеджере и размечен аттрибутами).
Ну и нужно держать синхронизованными xml-описание схемы стиля и код, использующий ключи для доступа к параметру схемы.
Здравствуйте, WFrag, Вы писали:
WF>Ну да, можно просто в неком xml задавать, какие вообще бывают настройки стиля, т.е описание, название(ключ), тип. А контрол просто просит у менеджера по заданным ключам элемент стиля.
Подумал еще немного . Смысла делать xml с набором свойств, управляемых стилизатором, по-моему, нет. Все равно он будет сильно завязан на код, поэтому, все же, самый простой вариант будет сделать конфиг, такой же, как и Config.cs.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, WFrag, Вы писали:
WF>>Короче, может стоит начать все это делать?
AVK>Ну сделай пока тестовый проектик, без януса.
Здравствуйте, AndrewVK, Вы писали:
WF>Правда непонятно, как, например, при загрузке устанавливать все цвета? Можно просто обходить дерево контролов, искать у них Color-свойства с нужным аттрибутом, искать в карте настроек цвет и его устанавливать.
AVK>Вот только нужно не только цвета, но еще и шрифты хотя бы настраивать.
Да какая разница. Если задать фрифт для формы/контрола, то все цвета и шрифты которые небыли заданы вручную будут считаны с парента.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
VD>Сначала нужно сериализацию для цветов сделать.
AVK>Да, проблема.
Да. Я вот дернулся... думал все просто. А оказалоь, что не очень.
Мне нужно в программе иметь доступ к ывету, а не к стороке (иначе будут тромоза). Да и самому броузеру свойство тоже нужен колор (он, то вотличии от кривого сериалайзера цвет понимает). А сериализовать нужно именно строку. Конвертер конечно есть, но вызывать его должен именно сериалайзер. Надо бы что-то там поправит, если публичных свойств нет, чтобы производилась попытка конвертировать в строку.
VD>У нашего сериализатора конфигов позгов не хватает чтобы сохранить цвета.
AVK>Сериализатор тут не при чем. При чем Color.
Не надо песен. Форматеры цвет сохраняют влет. Он атрибутом Serializable помечен.
VD>В общем, вся задача сводится к превращению цвета в строку и обратно.
AVK>Эта задача уже решена, называется ColorTypeConvertor.
Языком. А ты сделай чтобы твой конфиг цвета сериализовал.
AVK>Я думаю не стоит в конфиге хранить всю схему. Лучше только имя файла, а саму схему в отдельном файле, чтобы человек мог просто готовый файл скачать.
Зачем эти сложности? Ваши схемы — это не боле чем набор цветов, который просто нужно в тупую копировать поверх текущих.
Не надо делать извращений. Иначе нельзя будет поменять один цвет.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WFrag, Вы писали:
WF>Это не проблема. Поиск по РСДН-у, как и говорил АВК, дал вполне определенный результат.
Не проблема? Ну, так во и реши ее для начала. Причем так чтобы в будущем не приходилось трахаться с каждым таким свойством.
WF>Я хотел другой способ. Не формы/контролы опрашивают конфиг о цветах, а специальный менеджер обходит формы/контролы и устанавливает в них экспортированные (посредством аттрибута) цвета в значение из конфига. Аттрибут также нужен для описания цвета. Например вот так (в ForumDummyForm.cs)
Да не нужен никакой менеджер. Есть только цвет фона и текста. Которые прекрасно можно установить на основную форму. Остальные съедят его автоматом. А цвета вроде цвета подсветки ответов один фиг из конфига читать.
И вообще схема на собятиях будет надежнее обхода. Ведь если свойство не стандартное, то твой обход обламается.
WF>Далее отдаем на съедение нужные формы/контролы менеджеру, он их пробегает, строит список настраиваемых цветов, и вставляет их каким-нибудь образом в PropertyGrid,
Озверел что ли? Это будет список из 1000 посзиций.
Нужно ввести пару цветов общих и еще штуки 3-6 специальных. Не выдумывай сложностей. К тому, же теперь контролы и формы не грузатся при загрузке, а подгружаются по требованию. Так что ты просто их не увидишь.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, WFrag, Вы писали:
AVK>>>Ну сделай пока тестовый проектик, без януса.
WF>>Что именно?
AVK>Ну то что ты тут расписывал.
Здравствуйте, WFrag, Вы писали:
WF>Хотя, можно, например, в конструкторе контрола регистрироваться в менеджере (менеджер — синглтон). При этом, менеджер может держать слабые ссылки на зарегистрированные контролы (чтобы не продлевать их жизнь зря).
Тогда проще уж в этом конструкторе считать цвета и устанвить.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, SergeaS, Вы писали:
SS>Здравствуйте, WFrag, Вы писали:
WF>>Вот набросок идеи: http://ccfit.nsu.ru/~dubrov/Style.zip
SS>А нельзя-ли закачать, допустим, на RSDN, а то что-то сайт не грузится.
Здравствуйте, WFrag, Вы писали:
WF>Подумал еще немного . Смысла делать xml с набором свойств, управляемых стилизатором, по-моему, нет. Все равно он будет сильно завязан на код, поэтому, все же, самый простой вариант будет сделать конфиг, такой же, как и Config.cs.
Да не нужнен отдельный конфиг. Просто нужно добавить цвета.
PS
Заниметесь трепом. Соделайте мне нормальную сериализацию свойств типа Color и я вам за час сделаю поддержку цветов. А схемы сделаете простым копированием (пробежитесь по свойствам отберете тольк те что относятся к цветам и шрифтам и скопруете их в отдельный хмле и на оборот).
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Теперь о кривоте. Все же не здорово что программно будет видно два свойтсва одно текстовое, другое цетное. Нельзя ли сделать текстовое свойство протектед?
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, WFrag, Вы писали:
VD>Во. [XmlIgnore] — это все что было нужно.
VD>Теперь о кривоте. Все же не здорово что программно будет видно два свойтсва одно текстовое, другое цетное. Нельзя ли сделать текстовое свойство протектед?
Нельзя, XmlSerializer сериализует только публичные поля.
Или использовать не Color, а какой-нибудь CustomColor, который бы сериализовался XmlSerialize-ом (публичные поля были бы еще и на запись). Но тогда нужно будет сделать, чтобы PropertyGrid его правильно понимал. Еще нужно будет к нему ColorEditor прикрутить... Короче, ничего приятного .
В принципе, ничего плохого в двух свойствах нет . Разный взгляд на одни и те же данные.
Здравствуйте, VladD2, Вы писали:
VD>Да не нужнен отдельный конфиг. Просто нужно добавить цвета.
VD>PS
VD>Заниметесь трепом. Соделайте мне нормальную сериализацию свойств типа Color и я вам за час сделаю поддержку цветов. А схемы сделаете простым копированием (пробежитесь по свойствам отберете тольк те что относятся к цветам и шрифтам и скопруете их в отдельный хмле и на оборот).
Нет, лучше отдельную закладку сделать. Нефиг все в одну кучу кидать.
P.S. А насчет трепа — лучше все заранее обдумать. Торопиться с кодингом не стоит, все же нет цели сделать функциональность за ограниченный срок. Тем более стили — это не так критично
Здравствуйте, VladD2, Вы писали:
AVK>>Вот только нужно не только цвета, но еще и шрифты хотя бы настраивать.
VD>Да какая разница. Если задать фрифт для формы/контрола, то все цвета и шрифты которые небыли заданы вручную будут считаны с парента.
Но для парента то задать надо? Да и потом — у браузера от парента ничего не отнаследуется, надо стили править.
Здравствуйте, VladD2, Вы писали:
VD>Да. Я вот дернулся... думал все просто. А оказалоь, что не очень.
Ну так поиск или спросить.
VD>Мне нужно в программе иметь доступ к ывету, а не к стороке (иначе будут тромоза).
Да никаких проблем. Сделай два свойства — одно для сериализации, другое для доступа. Или кешируй внутри своих классов
VD>Да и самому броузеру свойство тоже нужен колор (он, то вотличии от кривого сериалайзера цвет понимает).
Блин, надоели твои вопли уже про кривоту. Надо разобраться, а потом орать. Я тебе еще раз говорю — это нормальное явление, сериалайзер работает именно так как должен.
VD>А сериализовать нужно именно строку. Конвертер конечно есть, но вызывать его должен именно сериалайзер. Надо бы что-то там поправит, если публичных свойств нет, чтобы производилась попытка конвертировать в строку.
Слишком многого ты от него хочешь. Если подобные выверты реализовывать, то получится нафик икому не нужный монстр. Тем им хорош XmlSerializer, что все его действия подконтрольны. И слава богу что в нем нет такой хитрой и неочевидной логики.
AVK>>Сериализатор тут не при чем. При чем Color.
VD>Не надо песен. Форматеры цвет сохраняют влет. Он атрибутом Serializable помечен.
XmlSerializer это не форматтер.
AVK>>Эта задача уже решена, называется ColorTypeConvertor.
VD>Языком. А ты сделай чтобы твой конфиг цвета сериализовал.
А сам что, не можешь?
AVK>>Я думаю не стоит в конфиге хранить всю схему. Лучше только имя файла, а саму схему в отдельном файле, чтобы человек мог просто готовый файл скачать.
VD>Зачем эти сложности? Ваши схемы — это не боле чем набор цветов, который просто нужно в тупую копировать поверх текущих.
VD>Не надо делать извращений. Иначе нельзя будет поменять один цвет.
Ну ну. Если я захочу схему с сайта поставить мне придется руками конфиг править? Может это как раз и есть извращение?
Здравствуйте, WFrag, Вы писали:
WF>P.S. А насчет трепа — лучше все заранее обдумать. Торопиться с кодингом не стоит, все же нет цели сделать функциональность за ограниченный срок.
Здравствуйте, WFrag, Вы писали:
WF>Нет, лучше отдельную закладку сделать. Нефиг все в одну кучу кидать.
Какую кучу? Будет раздел "Цвета". Нафиг мне 22 закладки? А галвное, нафиг мне два одинаковых конфига?
WF>P.S. А насчет трепа — лучше все заранее обдумать. Торопиться с кодингом не стоит, все же нет цели сделать функциональность за ограниченный срок. Тем более стили — это не так критично
Нам нужно уже сейчас цвета для подсветки своих сообщений. И это критично.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WFrag, Вы писали:
WF>Нельзя, XmlSerializer сериализует только публичные поля.
Хорошо. А есть какой-нить IXmlSerializeble? Можно ручную сериализацию для цвета или обртки над ним сделать?
WF>Или использовать не Color, а какой-нибудь CustomColor, который бы сериализовался XmlSerialize-ом (публичные поля были бы еще и на запись). Но тогда нужно будет сделать, чтобы PropertyGrid его правильно понимал. Еще нужно будет к нему ColorEditor прикрутить... Короче, ничего приятного .
WF>В принципе, ничего плохого в двух свойствах нет . Разный взгляд на одни и те же данные.
Это и плохо. Не смертельно. Но плохо.
Ладно. Пока пусть так.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
VD>Да. Я вот дернулся... думал все просто. А оказалоь, что не очень.
AVK>Ну так поиск или спросить.
Я у тебя спросил. Более того проситл тебя сделать. Ты вредничать начал.
AVK>Да никаких проблем. Сделай два свойства — одно для сериализации, другое для доступа. Или кешируй внутри своих классов
Два — это криво. Хотя похоже другого выхода нет. Вернее другой — это совсем сложно. А кэшировать — это тоже криво, неудобно.
VD>Да и самому броузеру свойство тоже нужен колор (он, то вотличии от кривого сериалайзера цвет понимает).
AVK>Блин, надоели твои вопли уже про кривоту. Надо разобраться, а потом орать. Я тебе еще раз говорю — это нормальное явление,
В чем? Все и так ясно. Схема сериализации отлична от той на которую рассчитан Color (не стандартная). От сюда и проблемы.
AVK>сериалайзер работает именно так как должен.
Он работает плохо. Не удобно. Средств расширения нет. Нефига защищать кривые вещи.
AVK>Слишком многого ты от него хочешь. Если подобные выверты реализовывать, то получится нафик икому не нужный монстр. Тем им хорош XmlSerializer, что все его действия подконтрольны. И слава богу что в нем нет такой хитрой и неочевидной логики.
Какой монстр? Все форматеры цвет едет на ура. В КодДом он сериализуется влет. А этот не может. Кривь — это.
AVK>XmlSerializer это не форматтер.
Ну, и? КодДом тоже. Но тем не менее цвет жрет. В общем, еще раз. Не придумывай орпавдания для надоделанных решений. Может где-то его и достаточно, но нам бы как раз подходит плохо.
AVK>>Эта задача уже решена, называется ColorTypeConvertor. VD>Языком. А ты сделай чтобы твой конфиг цвета сериализовал. AVK>А сам что, не можешь?
Если бы мог, давно сдела бы. Я в его алгоритмах ни ухом ни рылом.
AVK>Ну ну. Если я захочу схему с сайта поставить мне придется руками конфиг править? Может это как раз и есть извращение?
Зачем? Сделай отдельное свойство "Цветовая схема". Или отдельную закладку. На ней выдавай список схем (из хмл-ных файлов) и просто коприуй значения из выбранной в конфиг. Просто, удобно и всегда можно зименить одно значение не меняя всей схемы.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
AVK>>Ну так поиск или спросить.
VD>Я у тебя спросил.
Я тебе ответил
VD>Более того проситл тебя сделать. Ты вредничать начал.
Я не вредничать начал, нет пока возможности делать все сразу. Вон до сих пор непонятно что с тулбаром делать.
AVK>>Блин, надоели твои вопли уже про кривоту. Надо разобраться, а потом орать. Я тебе еще раз говорю — это нормальное явление,
VD>В чем? Все и так ясно. Схема сериализации отлична от той на которую рассчитан Color (не стандартная).
Не надо путать XmlSerializer и форматтеры, ну сколько можно повторять. XmlSerializer не предназначен для хранения любых классов, он предназначен для автоматического преобразования определенных классов в заданную структуру. Т.е фактически просто способ упростить чтение/запись данных в/из xml. Вот из этого и надо исходить.
VD>Он работает плохо. Не удобно. Средств расширения нет. Нефига защищать кривые вещи.
Средства расширения есть и нормально он работает. Просто цели и задачи у него совершенно иные. Хочешь универсальной сериализации любых объектов, пользуй форматтер. XmlSerializer не для этого.
VD>Какой монстр? Все форматеры цвет едет на ура.
Потому что это форматтеры, у них задача сериализовать все и вся.
VD>В КодДом он сериализуется влет.
Потому что TypeConverter для Color специально заточен под это и умеет преобразовывать его в InstanceDescriptor.
AVK>>XmlSerializer это не форматтер.
VD>Ну, и?
Ну и не надо от него требовать свойств форматтера.
VD> КодДом тоже. Но тем не менее цвет жрет.
Потому что Color специально под CodeDOM заточен.
AVK>>А сам что, не можешь?
VD>Если бы мог, давно сдела бы. Я в его алгоритмах ни ухом ни рылом.
А тебе не надо никаких алгоритмов знать. Тебе просто нужно объявить два свойства:
private Color _SomeColor;
[XmlIgnore]
public Color SomeColor
{
get { return _SomeColor; }
set { _SomeColor = value; }
}
[Browsable(false)]
public string SerSomeColor
{
get { TypeDescriptor.GetConverter(typeof (Color)).ConvertToString(_SomeColor);}
set { _SomeColor = TypeDescriptor.GetConverter(typeof (Color)).ConvertFromString(value); }
}
AVK>>Ну ну. Если я захочу схему с сайта поставить мне придется руками конфиг править? Может это как раз и есть извращение?
VD>Зачем? Сделай отдельное свойство "Цветовая схема". Или отдельную закладку. На ней выдавай список схем (из хмл-ных файлов) и просто коприуй значения из выбранной в конфиг. Просто, удобно и всегда можно зименить одно значение не меняя всей схемы.
Не знаю, не нравится мне это решение, слишком много телодвижений.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, VladD2, Вы писали:
AVK>>Ну так поиск или спросить.
VD>Я у тебя спросил.
AVK>Я тебе ответил
Точнее сказать отбрехался.
AVK>Не надо путать XmlSerializer и форматтеры, ну сколько можно повторять. XmlSerializer не предназначен для хранения любых классов, он предназначен для автоматического преобразования определенных классов в заданную структуру. Т.е фактически просто способ упростить чтение/запись данных в/из xml. Вот из этого и надо исходить.
Значит в данном случае он использован не по назначению. В конфиге должны сериализоваться любые типы.
AVK>А тебе не надо никаких алгоритмов знать. Тебе просто нужно объявить два свойства: AVK>
AVK>private Color _SomeColor;
AVK>[XmlIgnore]
AVK>public Color SomeColor
AVK>{
AVK> get { return _SomeColor; }
AVK> set { _SomeColor = value; }
AVK>}
AVK>[Browsable(false)]
AVK>public string SerSomeColor
AVK>{
AVK> get { TypeDescriptor.GetConverter(typeof (Color)).ConvertToString(_SomeColor);}
AVK> set { _SomeColor = TypeDescriptor.GetConverter(typeof (Color)).ConvertFromString(value); }
AVK>}
AVK>
Собственно это от тебя и росли. Если бы ты не вредничал, давно уже были бы настраиваемые цвета.
VD>Зачем? Сделай отдельное свойство "Цветовая схема". Или отдельную закладку. На ней выдавай список схем (из хмл-ных файлов) и просто коприуй значения из выбранной в конфиг. Просто, удобно и всегда можно зименить одно значение не меняя всей схемы.
AVK>Не знаю, не нравится мне это решение, слишком много телодвижений.
Каких? Не придумывай находу. В любом другом случае траха будт в разы больше.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
VD>Хорошо. А есть какой-нить IXmlSerializeble?
AVK>Есть
Ну, так может написать обертку? Не трахаться же так каждый раз?
AVK>Для цвета нельзя, это структура. А для обертки придется еще свой Editor писать, но для обертки XmlSerializable не нужен.
Зачем свой? Редактор уже есть. Нужно только перемап сделать. Чтобы он вместо самого класса цвет менял.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
AVK>>Я тебе ответил
VD>Точнее сказать отбрехался.
Что значит отбрехался? Я тебе объяснил в чем проблема. Ты все таки не чайник, тебе же не нужно элементарные вещи разжевывать.
VD>Значит в данном случае он использован не по назначению. В конфиге должны сериализоваться любые типы.
Ну так предложи вариант лучше. Вариант переписать XmlSerializer не лучший
VD>Собственно это от тебя и росли. Если бы ты не вредничал, давно уже были бы настраиваемые цвета.
Я думал что тебе не надо элементарные вещи объяснять.
VD>>Зачем? Сделай отдельное свойство "Цветовая схема". Или отдельную закладку. На ней выдавай список схем (из хмл-ных файлов) и просто коприуй значения из выбранной в конфиг. Просто, удобно и всегда можно зименить одно значение не меняя всей схемы.
AVK>>Не знаю, не нравится мне это решение, слишком много телодвижений.
VD>Каких?
Со стороны пользователя
1) Скачал в нужный каталог
2) зашел в настройку, нажал кнопку загрузить, загрузил
3) Выбрал загруженную схему
В случае отдельного файла достаточно положить файл в каталог, а затем в настройках его выбрать. При обновлениях еще проще — просто заменяем файл.
Со стороны программера
1) Создать класс, представляющий схему
2) создать сериализуемую в xml коллекцию схем
3) написать редактор этой коллекции, чтобы было можно погружать в нее внешние файлы
В случае же отдельного файла достаточно 1 строковое свойство и подключить к нему FileNameEditor
VD> Не придумывай находу. В любом другом случае траха будт в разы больше.
Это вряд ли. Я уже с пресетами наелся. Там как раз реализовано так как ты предлагаешь. Траху по самое нехочу.
Здравствуйте, VladD2, Вы писали:
VD>Ну, так может написать обертку? Не трахаться же так каждый раз?
Для обертки IXmlSerializable не нужно.
AVK>>Для цвета нельзя, это структура. А для обертки придется еще свой Editor писать, но для обертки XmlSerializable не нужен.
VD>Зачем свой? Редактор уже есть. Нужно только перемап сделать.
Здравствуйте, AndrewVK, Вы писали:
AVK>Что значит отбрехался? Я тебе объяснил в чем проблема. Ты все таки не чайник, тебе же не нужно элементарные вещи разжевывать.
Если я спрашиваю, значит я не знаю. И мне нужен не отбрех, а ответ.
AVK>Ну так предложи вариант лучше. Вариант переписать XmlSerializer не лучший
В принципе конечно лучшуй, но не самый простой.
VD>Собственно это от тебя и росли. Если бы ты не вредничал, давно уже были бы настраиваемые цвета. AVK>Я думал что тебе не надо элементарные вещи объяснять.
Я с этим еще рне возлся. Дернулся... не вышло... дернул тебя... ты полез вредничать.
AVK>Со стороны пользователя AVK>1) Скачал в нужный каталог AVK>2) зашел в настройку, нажал кнопку загрузить, загрузил AVK>3) Выбрал загруженную схему
AVK>В случае отдельного файла достаточно положить файл в каталог, а затем в настройках его выбрать. При обновлениях еще проще — просто заменяем файл.
Все тоже самое. Скачал, положил, выбрал. Снова у тебя аргументов нет и ты притягиваешь их за уши.
AVK>Со стороны программера AVK>1) Создать класс, представляющий схему AVK>2) создать сериализуемую в xml коллекцию схем AVK>3) написать редактор этой коллекции, чтобы было можно погружать в нее внешние файлы
AVK>В случае же отдельного файла достаточно 1 строковое свойство и подключить к нему FileNameEditor
Та же фигня. Схема будет в отдельном файле, а цвета цветами.
В общем это притягивание за уши. Ты лучше скажи что ты будешь делать когда пользователь захочет изменить один цвет? Заставишь его фйл править или будешь ще один редактор конфигов делать?
VD> Не придумывай находу. В любом другом случае траха будт в разы больше.
AVK>Это вряд ли. Я уже с пресетами наелся. Там как раз реализовано так как ты предлагаешь. Траху по самое нехочу.
И в чем он? Пробежаться и отобрать свойства одного типа?
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, 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.
Вложенным классом сделать цвета конечно можно. А зачем его "При загрузке пресет поднимать" и т.д.? Пускай в конфиг и сериализуется.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Но вот WFrag почему то моих объяснений хватило.
Значит он знал больше. Собственно у него я и увидил то что было нужно (атрибут заперщающий сериализацию)
VD>В общем это притягивание за уши.
AVK>Извини, но я подобное уже делал, а ты нет. И твои неаргументированные утверждения меня не убедили.
Не аргументированные утверждения именно твои. Я уже сказал, что второй конфиг — это зло. И нужо иметь возможность настраивать каждый цвет отдельно. Это все означает, что данные нужно хранить именно в конфиге.
Можно все цвета сделать отдельным подклассом который при загрузке пресета будет полностью подменяться. Но сохранять занчения нужно именно в конфиг. Не дело это когда настройки в разный местах.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WFrag, Вы писали:
WF>1. Config.cs содержит свойство StyleConfig, которое ссылается на синглтон StyleConfig-а, т.е текущая схема таким образом автоматически сохраняется внутри Config-а.
Значит можно будет менять отдельные поля? Это хорошо.
WF>2. StyleConfig содержит статическое событие, которое запускается, если было изменено какое-то свойство (т.е подписанные контролы обновляются сразу при изменении какого-либо свойства).
Сразу не надо. Надо только после нажатия ОК в диалоге настройки.
WF>3. Контролы могут подписываться где-нибудь в конструкторе, отписываться в Dispose.
На есть событие изменение конфига можно на него все и изменять.
WF>4. StyleConfig может быть сохранен/загружен отдельно от Config-а — внешние схемы.
Нужен или диалог или закладку для выбора темы/стиля.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, 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.
Правда, там есть баг:
Если обратиться к StyleConfig.Instance, а StyleConfig и Config еще не загружены — то создастся схема по умолчанию.
Если же обратиться через Config.Instance.StyleConfig — то сначала загрузится Config, он загрузит в процессе StyleConfig и , соответственно, будут схемы из конфига.
Можно сделать, чтобы StyleConfig.Instance форсировало pfuhepre rjyabuf (вызовом Config.Instance). Но это как-то некузяво.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, AndrewVK, Вы писали:
AVK>>Но вот WFrag почему то моих объяснений хватило.
VD>Значит он знал больше. Собственно у него я и увидил то что было нужно (атрибут заперщающий сериализацию)
Ради справедливости замечу, что мне хватило объяснения "было на РСДН".
Здравствуйте, 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 и ставят его.
Ну, подключай к Хоуму. Будем поглядать.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
WF>В общем, у меня уже есть прикрученная к Янусу базовая настройка цветов. Может ее стоит залить, тогда мне доступ в CVS нужен .
AVK>Не, ты для начала распиши что ты там нагородил.
Да вчем проблема. Пусть заливает. Откатить если что не долго.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WFrag, Вы писали:
WF>4. Добавлена закладка в OptionsForm. WF>При открытии OptionsForm текущая настройка стиля сохраняется, а все изменения (PropertyGrid-ом) идут сразу в синглтон StyleConfig-а, при этом тот рассылает сообщение о измене настроек стиля.
Не. Так дело не пойдет. Редактировать надо копию и только по ОК применять.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, WFrag, Вы писали:
WF>Если же обратиться через Config.Instance.StyleConfig — то сначала загрузится Config, он загрузит в процессе StyleConfig и , соответственно, будут схемы из конфига.
Так к StyleConfig и нужно через Config доступ получать. А на прямое обращение нужно как-то посылать на фиг.
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, WFrag, Вы писали:
WF>>>1. Config.cs содержит свойство StyleConfig, которое ссылается на синглтон StyleConfig-а, т.е текущая схема таким образом автоматически сохраняется внутри Config-а.
VD>>Значит можно будет менять отдельные поля? Это хорошо.
WF>>Не понял .
VD>Ну, можно будет заменить один цвет, а не всю схему?
VD>>Сразу не надо. Надо только после нажатия ОК в диалоге настройки. WF>>А почему? Довольно удобно . Сразу видно все изменения. Хотя, как будет на тормозных машинах, не знаю.
VD>Это вообще не верно. Зачем тогда вообще ОК нужен? Ну, и главно нельзя будет откатить изменения.
Ну так все и откатывается. При загрузке OptionsDialog, текущее состояние StyleConfig сохраняется, все изменения идут на оригинале, при этом контролы тут же обновляются. Жмешь "Отмена" — восстанавливается старая копия, жмешь "OK" — ничего не делается.
WF>>Ну можно и так, если убрать пункт выше, т.е менять только после OK.
VD>Только так и нужно. Или тебе придется еще анду-буфер делать. А потом все это объяснять пользователям у которых уже сложились понятия о том как работают диалоги.
WF>>Все, что нашел, связанное с изменением конфига — в MainForm WF>>Features.Instance.ConfigChanged(); // <- Это все и обновляет? Все формы/контролы?
VD>Почти, но не совсем. Это оповещение фич об изменении. Вот код вызывающий диалог настроек:
VD>
VD>Вот перед вызовом Features.Instance.ConfigChanged(); и нужно вставлять апдэйт цветов.
WF>>Пока есть две кнопки — загрузить и сохранить пресет на новой закладке (на которой все настройки), обычные файловые диалоги. Грузят XmlSerializer-ом StyleConfig и ставят его.
VD>Ну, подключай к Хоуму. Будем поглядать.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, AndrewVK, Вы писали:
AVK>>А каким образом реализована поддержка схем?
VD>Как я понял этот клас можно будет просто менять.
А что такое тогда схема?
Есть некий класс содержащий цвета, шрифты. Он сохраняется вместе с конфигом, но его также его можно загрузить отдельно из отдельного файла — пресеты.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, WFrag, Вы писали:
WF>>4. Добавлена закладка в OptionsForm. WF>>При открытии OptionsForm текущая настройка стиля сохраняется, а все изменения (PropertyGrid-ом) идут сразу в синглтон StyleConfig-а, при этом тот рассылает сообщение о измене настроек стиля.
VD>Не. Так дело не пойдет. Редактировать надо копию и только по ОК применять.
Почему? Если жать отмена — восстановятся старые настройки, сохраненные перед изменениями.
Здравствуйте, WFrag, Вы писали:
WF>Есть некий класс содержащий цвета, шрифты. Он сохраняется вместе с конфигом, но его также его можно загрузить отдельно из отдельного файла — пресеты.
Здравствуйте, m.a.g., Вы писали:
MAG>Здравствуйте, WFrag, Вы писали:
WF>>Усе, залил. Можете ругать.
MAG>А чего это в настройках категории с 2 начинаются?
Категория 1 были общие настройки (кнопки плоские/не плоские, и.т.д). А теперь их пока нету . Это ж альфа (потому и тулбара два).
Здравствуйте, WFrag, Вы писали:
WF>Здравствуйте, m.a.g., Вы писали:
MAG>>Здравствуйте, WFrag, Вы писали:
WF>>>Усе, залил. Можете ругать.
MAG>>А чего это в настройках категории с 2 начинаются?
WF>Категория 1 были общие настройки (кнопки плоские/не плоские, и.т.д). А теперь их пока нету . Это ж альфа (потому и тулбара два).
Да я уже один оторвал у себя
Только вот я думал, что это у меня что-то глючит и поэтому категории 1 нету.
Здравствуйте, WFrag, Вы писали:
WF>Может я все же залью изменения, тем более там практически ничего и не изменено — так, понемногу. Тем более, всегда можно откатить.
Дык я так понял, что ты ужо...
... << RSDN@Home 1.1 alpha 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
.
.
