Аннотация:
Создание ПО из компонентов подразумевает, что компоненты будут добавляться к проекту во время разработки. При этом будет производиться их начальная настройка. Компоненты как таковые не подразумевают (вернее сказать, не обязаны иметь) пользовательского интерфейса (ни для программиста, ни для конечного пользователя). В этом качестве выступают части IDE и дополнительные программные дизайнеры. Первой компонентной средой был продукт, купленный Microsoft на заре своего существования. Впоследствии на его базе родился VB. Далее была Delphi… в общем, к концу двадцатого века компоненты стали поддерживаться почти везде (даже в Visual C++, хотя он и по сей день не очень-то визуальный).
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Владислав Чистяков, Вы писали:
ВЧ>Статья: ВЧ>.Net – классы, компоненты и контролы
ВЧ>Авторы: ВЧ> Владислав Чистяков
ВЧ>Аннотация: ВЧ>Создание ПО из компонентов подразумевает, что компоненты будут добавляться к проекту во время разработки. При этом будет производиться их начальная настройка. Компоненты как таковые не подразумевают (вернее сказать, не обязаны иметь) пользовательского интерфейса (ни для программиста, ни для конечного пользователя). В этом качестве выступают части IDE и дополнительные программные дизайнеры. Первой компонентной средой был продукт, купленный Microsoft на заре своего существования. Впоследствии на его базе родился VB. Далее была Delphi… в общем, к концу двадцатого века компоненты стали поддерживаться почти везде (даже в Visual C++, хотя он и по сей день не очень-то визуальный).
В статье рассказывается как создавать виртуальные свойства у компонентов в design time.
Вопрос как создать виртуальные свойства НЕ у компонента, то есть у произвольного класса.
Конкретно: хочу написать свой UITypeEditor для кисти, что бы свойство типа Brush можно было настраивать в PropertyGrid'е. Видится мне это так — Expandable object в котором есть комбобокс с возможными типами кисти и изменяющийся набор виртуальных свойств в зависимости от выбранного типа.
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Здравствуйте, Владислав Чистяков, Вы писали:
ВВ>В конце статьи кто-то обещал продолжение. А так как статья вышла уже энное время назад, то возникает естестественный вопрос.
Как то вдохновение не находит. К тому, же орлы из Редмонда уже многое сделали в этом направлении (в MSDN Magazine вышла пара статей в этом же духе).
В общем, если читатели сформулируют, что они хотели бы видеть в продолжении, может вдохновение и вернется. Пока думаю сделать статейку не о контролах, а о контейнере. Так сказать взгляд с другой стороны. Мне кажется, это будет куда нагляднее. Вот только объем работы очень большой. И сложность статьи тоже слишком велика (чистое грузилово).
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>В общем, если читатели сформулируют, что они хотели бы видеть в продолжении, может вдохновение и вернется.
Ну кое-что можно накопать. Например, рассмотреть по-этапно создание к-нить интересного гуйного контрола. Или основные способы создания меню с картинками — я знаю по крайней мере три — типа плюсы-минусы и все такое. Может интересно получиться.
VD>Пока думаю сделать статейку не о контролах, а о контейнере. Так сказать взгляд с другой стороны. Мне кажется, это будет куда нагляднее. Вот только объем работы очень большой. И сложность статьи тоже слишком велика (чистое грузилово).
Здравствуйте, Воронков Василий, Вы писали:
ВВ>Ну кое-что можно накопать. Например, рассмотреть по-этапно создание к-нить интересного гуйного контрола. Или основные способы создания меню с картинками — я знаю по крайней мере три — типа плюсы-минусы и все такое. Может интересно получиться.
Гы. Про контрол, я тоже так подумал. Создал простенький контрол (TreeGrid), но пока он создавался, он пережил полный редизайн и стал занимать 150 кил кода. Так что его описание займет пол журнала.
ВВ>А в чем основная идея?
Описать реализацию контейнера позволяющего хостить (настраивать/сериализовать/запускать) стандартные контролы. Там два момента: 1) кодогенерация (сериализация в код) и 2) дизантайм-опдсистема дизайнера.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Гы. Про контрол, я тоже так подумал. Создал простенький контрол (TreeGrid), но пока он создавался, он пережил полный редизайн и стал занимать 150 кил кода. Так что его описание займет пол журнала.
Ну зачем так увлекаться? С теми же меню явно получится куда скромнее. Код, кстати, могу дать.
ВВ>>А в чем основная идея? VD>Описать реализацию контейнера позволяющего хостить (настраивать/сериализовать/запускать) стандартные контролы. Там два момента: 1) кодогенерация (сериализация в код) и 2) дизантайм-опдсистема дизайнера.
Здравствуйте, Ed.ward, Вы писали:
EW>Конкретно: хочу написать свой UITypeEditor для кисти, что бы свойство типа Brush можно было настраивать в PropertyGrid'е. Видится мне это так — Expandable object в котором есть комбобокс с возможными типами кисти и изменяющийся набор виртуальных свойств в зависимости от выбранного типа.
EW>Спасибо за любую помощь.
EW>Ed.ward
Копай в сторону ICustomTypeDescriptor. Его реализацию надо передавать в качестве значения свойства Brush.
Т.е. что-то типа BrushWrapper(component.Brush), где BrushWrapper реализует ICustomTypeDescriptor.
Здравствуйте, Poudy, Вы писали:
P>Здравствуйте, Ed.ward, Вы писали:
EW>Конкретно: хочу написать свой UITypeEditor для кисти, что бы свойство типа Brush можно было настраивать в PropertyGrid'е. Видится мне это так — Expandable object в котором есть комбобокс с возможными типами кисти и изменяющийся набор виртуальных свойств в зависимости от выбранного типа.
EW>Спасибо за любую помощь.
EW>Ed.ward
P>Копай в сторону ICustomTypeDescriptor. Его реализацию надо передавать в качестве значения свойства Brush. P>Т.е. что-то типа BrushWrapper(component.Brush), где BrushWrapper реализует ICustomTypeDescriptor.
То есть ты имеешь ввиду что в настраивамом объекте надо объявлять поле типа BrushWrapper, а не Brush и в нем инкапсулировать Brush?
Здравствуйте, Ed.ward, Вы писали:
EW>То есть ты имеешь ввиду что в настраивамом объекте надо объявлять поле типа BrushWrapper, а не Brush и в нем инкапсулировать Brush?
Есть иного решений. Так можно сделать теневое свойство и в нем уже сделть подмену объекта на врапер. А можно и в самом объекте реализовать ICustomTypeDescriptor. Проперти-грид всегда пытается получить этот интерфейс от объекта и если это удается вся информация о типах ичитается через этот интерфейс.
... << RSDN@Home 1.1 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
О container можно написать реализацию wizard control. Кода не очень много. У меня в проекте 3 класса: PanelCollection, WizardControl, WizardControlDesigner. Можно добавить классы для реализации стандартных panels: WelcomePanel, SimplePanel, EndPanel, стандартные panels для инсталяции.
P.S. В статье не очень понятна реализация IMenuCommandService.
Здравствуйте, VladD2, Вы писали:
VD>Здравствуйте, Воронков Василий, Вы писали:
ВВ>>Ну кое-что можно накопать. Например, рассмотреть по-этапно создание к-нить интересного гуйного контрола. Или основные способы создания меню с картинками — я знаю по крайней мере три — типа плюсы-минусы и все такое. Может интересно получиться.
VD>Гы. Про контрол, я тоже так подумал. Создал простенький контрол (TreeGrid), но пока он создавался, он пережил полный редизайн и стал занимать 150 кил кода. Так что его описание займет пол журнала.
ВВ>>А в чем основная идея?
VD>Описать реализацию контейнера позволяющего хостить (настраивать/сериализовать/запускать) стандартные контролы. Там два момента: 1) кодогенерация (сериализация в код) и 2) дизантайм-опдсистема дизайнера.
Здравствуйте, Олег Гашев, Вы писали:
ОГ>О container можно написать реализацию wizard control. Кода не очень много. У меня в проекте 3 класса: PanelCollection, WizardControl, WizardControlDesigner. Можно добавить классы для реализации стандартных panels: WelcomePanel, SimplePanel, EndPanel, стандартные panels для инсталяции.
Так может и напишешь? Я так понимаю реализация у тебя уже есть.
Здравствуйте, Олег Гашев, Вы писали:
ОГ>Давай я тебе ответ дам через неделю, в воскресенье. Надо еще поработать над кодом. Не всё готово, но рабочий вариант уже есть.
Content – говорит сериализатору, что свойство должно сериализоваться «по содержимому». Это значение применяется для сериализации коллекций. Чтобы сериализовать свойство по содержимому, нужно, чтобы возвращаемый им объект реализовывал один из следующих методов:
public int Add(SomeElementType value);
public void AddRange(SomeElementType [] values) ;
Кроме этого объект должен реализовать интерфейсы IList и ICollection. Методы AddRange и Add определяются по имени и не имеют никакого отношения к этим интерфейсам.
Content используется не только для коллекций.
У меня Content используется для сериализации класса, который будет представлен в properties grid как expandable type.
Здравствуйте, Олег Гашев, Вы писали:
ОГ>Здравствуйте, Владислав Чистяков, Вы писали:
ОГ>
ОГ>Content – говорит сериализатору, что свойство должно сериализоваться «по содержимому». Это значение применяется для сериализации коллекций. Чтобы сериализовать свойство по содержимому, нужно, чтобы возвращаемый им объект реализовывал один из следующих методов:
ОГ>public int Add(SomeElementType value);
ОГ>public void AddRange(SomeElementType [] values) ;
ОГ>Кроме этого объект должен реализовать интерфейсы IList и ICollection. Методы AddRange и Add определяются по имени и не имеют никакого отношения к этим интерфейсам.
ОГ>Content используется не только для коллекций. ОГ>У меня Content используется для сериализации класса, который будет представлен в properties grid как expandable type.
Так, вроде никто и не утверждал, что Content только для коллекций. Данный атрибут просто показывает сериалайзеру копнуть это свойство вглубь...
VD>В общем, если читатели сформулируют, что они хотели бы видеть в продолжении, может вдохновение и вернется.
Здравствуйте.
Ну например проблема использования ActiveX компонентов на WinForms.
вот если кинуть MsFlexGrid На Net User контрол, а потом этот User контрол вставить в 3ий контрол MyContols, или вставить на несколько закладок Tab'а то при вызове Dispose формы с табом или контрола MyContols вылетают сообщения типа Windowless ActiveX controls are not supported.
Вот таких вот мелочей — куча.
Кстати, ваш AscGrid случайно не Windowless? если да то он не будет корректно работать на нет формах, табох и контролах
Здравствуйте, Grizzli, Вы писали:
G>Здравствуйте. G>Ну например проблема использования ActiveX компонентов на WinForms. G>вот если кинуть MsFlexGrid На Net User контрол, а потом этот User контрол вставить в 3ий контрол MyContols, или вставить на несколько закладок Tab'а то при вызове Dispose формы с табом или контрола MyContols вылетают сообщения типа Windowless ActiveX controls are not supported.
Честно говоря мне кажется, что ActiveX это плохой выбор для винйормс. Уже есть куча родных контролов.
G>Вот таких вот мелочей — куча. G>Кстати, ваш AscGrid случайно не Windowless? если да то он не будет корректно работать на нет формах, табох и контролах
Нет он не видовлес и более менее сносно работает на винформс. Но честно говоря... см. выше.
... << RSDN@Home 1.1.2 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Jenyay, Вы писали:
J>А там не слышно когда это будет? И будет ли еще 3-я бета?
Приходи на следующую .Net UG и сможешь задать этот вопрос лично. Я чесно говря как-то не задавался этим вопросом. До нового года выйдет и ладно. Оно уже сейчас вполне приемлемо. Мне ведь релизов не выпускать.
... << RSDN@Home 1.1.4 beta 7 rev. 466>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
ВЧ>Авторы: ВЧ> Владислав Чистяков
ВЧ>Аннотация: ВЧ>Создание ПО из компонентов подразумевает, что компоненты будут добавляться к проекту во время разработки. При этом будет производиться их начальная настройка. Компоненты как таковые не подразумевают (вернее сказать, не обязаны иметь) пользовательского интерфейса (ни для программиста, ни для конечного пользователя). В этом качестве выступают части IDE и дополнительные программные дизайнеры. Первой компонентной средой был продукт, купленный Microsoft на заре своего существования. Впоследствии на его базе родился VB. Далее была Delphi… в общем, к концу двадцатого века компоненты стали поддерживаться почти везде (даже в Visual C++, хотя он и по сей день не очень-то визуальный).
"ComVisible(true)]
bool DesignMode {get;}
DesignMode – говорит, находится ли компонент в режиме разработки, то есть, загружен компонент в дизайнере типа VS.NET, или что компонент создан кодом приложения. В принципе, совершенно бесполезное свойство, так как когда компонент находится в рантайме, ему попросту не подключают site. А стало быть, проверить данное свойство совершенно невозможно."
Неверно. Проверять можно в
Protected Overrides Sub OnLayout(ByVal levent As System.Windows.Forms.LayoutEventArgs)
Отлично работает!
Re: .Net – классы, компоненты и контролы
От:
Аноним
Дата:
12.05.09 20:49
Оценка:
Интересно, жива ли тема?
После включения для контрола (UserControl) дизайнера контрол "упал" вниз. Т.е. на форме он отображается, и при запуске приложения с ним можно работать. Но выделить его на форме не могу (например, чтобы поменять положение и/или размер). Он "падает" в нижний контейнер, где обычно лежат OpenFileDialog и т.д. И тут я уже могу с ним работать (смотреть/менять свойства и тд.).
Дизайнер почти полностью взят из статьи. Он замещает реальное свойство типа Type на виртуальное типа String. Также к виртуальному свойству прикручивается рукописный Editor.
А>Дизайнер почти полностью взят из статьи.
Там он унаследован от ComponentDesigner, поменяйте базовый класс на ControlDesigner
Re[2]: .Net – классы, компоненты и контролы
От:
Аноним
Дата:
13.05.09 05:25
Оценка:
Отлично. Спасибо, господа.
Re[3]: .Net – классы, компоненты и контролы
От:
Аноним
Дата:
14.05.09 06:44
Оценка:
Господа, снова нужна помощь. Сделал так, как понял, но не все работает.
Как я писал выше, имеется юзер контрол.
В нем есть свойство:
public Type BindForm
{
get
{
return bFormValue;
}
set
{
try
{
if (value.BaseType != typeof(Form) && value != typeof(Form))
{
throw new InvalidCastException("Должна быть форма.");
}
bFormValue = value;
}
catch (InvalidCastException ex)
{
MessageBox.Show(ex.Message);
}
}
}
Хочу редактировать это свойство особым образом. Смысл в том, чтобы разработчик выбирал, какую форму он хочет открыть (при нажатии кнопки на контроле).
Для этого "подменяю" реальное свойство виртуальным типа string:
protected override void PreFilterProperties(
System.Collections.IDictionary properties)
{
base.PreFilterProperties(properties);
//const string sPropName = "Тестовое свойство";const string sPropName = "BindForm";
// Добавляем виртуальное свойство, доступное только во время разработки.
properties[sPropName] = new BindFormPropertyDescriptor(this,
TypeDescriptor.CreateProperty(
Component.GetType(),
sPropName,
typeof(String),
new Attribute[]
{
// Задаем категорию, в которой будет отображаться новое свойство.
CategoryAttribute.Data
// Говорим VS.NET, что при изменении этого свойства нужно
// перечитать значение остальных свойств.
, RefreshPropertiesAttribute.All
//Назначим свой редактор для свойства
, new EditorAttribute(typeof(BindFormEditor), typeof(System.Drawing.Design.UITypeEditor))
}));
}
Далее, реализую Editor для установки значения для этого виртуального свойства. Код приводить не будет, он большой.
Короче, до этого момента все работает замечательно.
Теперь хочу сделанные изменения сеарилизовать в код, чтобы он (она — Студия) записывал значение реального поля в Designer.cs
Для этого реализовал TypeConverter, чтобы строку переводить в нужный тип. Пример взят частично из MSDN, частично отсюда.
public class FromTypeConverter : TypeConverter
{
// Overrides the CanConvertFrom method of TypeConverter.
// The ITypeDescriptorContext interface provides the context for the
// conversion. Typically, this interface is used at design time to
// provide information about the design-time container.public override bool CanConvertFrom(ITypeDescriptorContext context, Type sourceType)
{
MessageBox.Show("FromTypeConverter.CanConvertFrom");
if (sourceType == typeof(string))
{
return true;
}
return base.CanConvertFrom(context, sourceType);
}
// Overrides the ConvertFrom method of TypeConverter.public override object ConvertFrom(ITypeDescriptorContext context, CultureInfo culture, object value)
{
try
{
MessageBox.Show("FromTypeConverter.ConvertFrom");
if (value is string)
{
//string[] v = ((string)value).Split(new char[] { ',' });
//return new Point(int.Parse(v[0]), int.Parse(v[1]));if (value.ToString() == "")
{
return null;
}
else
{
return Type.GetType(value.ToString());
}
}
return base.ConvertFrom(context, culture, value);
}
catch (System.IO.FileNotFoundException ex)
{
MessageBox.Show(ex.Message);
return base.ConvertFrom(context, culture, value);
}
}
public override bool CanConvertTo(ITypeDescriptorContext context, Type destinationType)
{
MessageBox.Show("FromTypeConverter.CanConvertTo");
if (destinationType == typeof(InstanceDescriptor))
return true;
// Всегда вызываем базовый класс если не можем
// совершить преобразование сами.return base.CanConvertTo(context, destinationType);
}
// Overrides the ConvertTo method of TypeConverter.public override object ConvertTo(ITypeDescriptorContext context,
CultureInfo culture, object value, Type destinationType)
{
MessageBox.Show("FromTypeConverter.ConvertTo");
if (destinationType == typeof(string))
{
//return ((Point)value).X + "," + ((Point)value).Y;return ((Type)value).AssemblyQualifiedName;
}
return base.ConvertTo(context, culture, value, destinationType);
}
}
Ну и теперь включаю непосредственно сериализацию (или думаю, что включаю):
[TypeConverter(typeof(FromTypeConverter))] //Вот тут
[Designer(typeof(BindFormComponentDesigner)), DesignerCategory("Default")] //А это дизайнер для виртуального создания свойстваpublic partial class UserControl1 : UserControl
Так вот ничего не происходит. Полученное значение не записывает в исходный код. В самом поле я его вижу, могу даже поменять и т.д. А как его в исходник загнать?
А>Так вот ничего не происходит. Полученное значение не записывает в исходный код. В самом поле я его вижу, могу даже поменять и т.д. А как его в исходник загнать?
А>Что я делаю не так?
А>Спасибо.
Народ, разобрался.
Мож кому понадобится.
Был неправильно реализован Conveter
Вместо:
// Overrides the ConvertTo method of TypeConverter.public override object ConvertTo(ITypeDescriptorContext context,
CultureInfo culture, object value, Type destinationType)
{
if (destinationType == typeof(string))
{
//Если тип назначения - строка, то вернем полное имя сборкиreturn ((Type)value).AssemblyQualifiedName;
}
//Все другие типы пусть конвертирует базовый классreturn base.ConvertTo(context, culture, value, destinationType);
}
Нужно было просто написать:
public override object ConvertTo(ITypeDescriptorContext context,
CultureInfo culture, object value, Type destinationType)
{
//Вернем значение поля, к. редактируемreturn ((UserControl1)value).BindForm;
}
Т.е. не нужно было передавать право преобразования в базовый класс. А просто вернуть значение свойства.
Так же полностью отказался от использования виртуальных свойств. Дизайнером для класса назначил стандартный. Вот полный заголовок:
//Теперь первый аттрибут можно и не указывать
//[Designer(typeof(/*BindFormComponentDesigner*/ControlDesigner)), DesignerCategory("Default")]
[TypeConverter(typeof(FormTypeConverter))]
[Serializable]
public partial class UserControl1 : UserControl
{...}
А Editor использовал для свойства напрямую:
[Editor(typeof(BindFormEditor), typeof(System.Drawing.Design.UITypeEditor))]
public Type BindForm
{ get; set; }
В результате пропала возможность править значение прямо в поле свойства. Но это даже и к лучшему (защита от дурака). А саму строку для извлечения типа формирую в самописной форме, к. вызывается при нажатии кнопки с троеточием.
