Аннотация:
Создание ПО из компонентов подразумевает, что компоненты будут добавляться к проекту во время разработки. При этом будет производиться их начальная настройка. Компоненты как таковые не подразумевают (вернее сказать, не обязаны иметь) пользовательского интерфейса (ни для программиста, ни для конечного пользователя). В этом качестве выступают части 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 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
