Здравствуйте, Mr.Gremlin, Вы писали:
MG>Чтобы в PropertyGrid можно было подсунуть свой ServiceProvider, достаточно переопределить метод GetService у PropertyGrid.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Mr.Gremlin, Вы писали:
MG>>Чтобы в PropertyGrid можно было подсунуть свой ServiceProvider, достаточно переопределить метод GetService у PropertyGrid.
AVK>Component.GetService: AVK>
AVK>Так что никакой разницы, но имхо с Site более правильно.
AVK>P.S. — никаких глюков не обнаружено, все сервисы нормально гридом зовутся, даже те что в студии не используются.
Прогнал, думал сайт у компонента, который броузится PropertyGrid-ом, подменять. А так это действительно тот-же результат. Но в случае если есть уже нормальный сайт, то с подменной возможны трудности. Хотя если есть сайт, то что-то подменять смысла нет. Вообщем трудно сказать что более правильно, я выбрал такой способ, кто-то другой, думаю еще есть варианты. Но имхо мой вариант более жизнеспособный .
Здравствуйте, Igor Trofimov, Вы писали:
iT>Отлично! Может у тебя есть другой рецепт выяснения, находится ли форма в design-time? iT>Или может "если это нужно знать, значит, ошибка в дизайне"?
Опиши проблему — найдем решение или укажем на ошибку.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, <Аноним>, Вы писали:
А>Help я прочитал, но так и не понял как его реализовать.. А>Вы не мудрите, вы пальцем покажите... А>Обьясние если можно на пальцах и с маленьким примером.
Нда. Может проше книгу каку по языку прочесть или стандарт?
В краце: береш компонент в котором нужно делать пост-инициализационные действия. Встаешь в его список реализуемых интерфейсов... Пишеш "ISupportInitialize" и нажимаешь TAB. Студия докинывает пустышки метдов.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, AndrewVK, Вы писали:
AVK>Чтобы в PropertyGrid можно было подсунуть в рантайме свой ServiceProvider. Сайт притом не самопальный, а вполне себе родной, фреймворковский.
PropertyGrid — это уже дизайнер.
... << RSDN@Home 1.1.3 beta 2 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
AVK>>Чтобы в PropertyGrid можно было подсунуть в рантайме свой ServiceProvider. Сайт притом не самопальный, а вполне себе родной, фреймворковский.
VD>PropertyGrid — это уже дизайнер.
Здравствуйте, AndrewVK, Вы писали:
AVK>IDesignerHost вполне может обнаружится и в рантайме.
А это не означает, что компонент всё-таки в дизайне, несмотря на то, что система в рантайме?
Здравствуйте, orangy, Вы писали:
AVK>>IDesignerHost вполне может обнаружится и в рантайме. O>А это не означает, что компонент всё-таки в дизайне, несмотря на то, что система в рантайме?
Не обязательно. Тут вопрос встает зачем вобще понадобилось обосабливать дизайнтайм.
Здравствуйте, AndrewVK, Вы писали:
AVK>>>IDesignerHost вполне может обнаружится и в рантайме. O>>А это не означает, что компонент всё-таки в дизайне, несмотря на то, что система в рантайме?
AVK>Не обязательно. Тут вопрос встает зачем вобще понадобилось обосабливать дизайнтайм.
Бывает нужно. Теоретически можно всё решить кастомными дизайнерами, но ради того, чтобы несколько поиному отрисоваться городить дизайнер не хочется. У меня, например, LayoutPanel в дизайне подсвечивает зоны, чтобы видно было раскладку.
Задача все та же — точно определить, находится ли форма в DesignTime или в RunTime. Из любого метода/конструктора. Предположим, что в самой проге (RunTime) — никаких дизайнерских штучек нет. То есть речь идет о вариантах VisualStudio / Application
VD>Опиши проблему — найдем решение или укажем на ошибку.
Повторяю.
Задача все та же — точно определить, находится ли форма в DesignTime или в RunTime. Из любого метода/конструктора. Предположим, что в самой проге (RunTime) — никаких дизайнерских штучек нет. То есть речь идет о вариантах VisualStudio / Application
Повторяю. Проверка свойства ISite на null — недостаточна. Как я написал выше, там может быть null и когда форма создается в дизайнере студии, поскольку дизайнер студии устанавливает это свойство довольно поздно (впрочем, он и не может раньше).
Здравствуйте, Igor Trofimov, Вы писали:
iT>Задача все та же — точно определить, находится ли форма в DesignTime или в RunTime. Из любого метода/конструктора.
Так не надо делать в конструкторе вещи которые там делать не надо. Сайт назначается после создания объекта, т.п. после того как конструктор уже отработал. Процес же конструирования еще идет. Перенеси нужный тебе код в место где сайт уже точно есть.
iT>Предположим, что в самой проге (RunTime) — никаких дизайнерских штучек нет. То есть речь идет о вариантах VisualStudio / Application
Для этого вообще стоит отдельный дизайнер завесит. Тогда он будет подгружаться исключительно средой.
iT>Повторяю. Проверка свойства ISite на null — недостаточна. Как я написал выше, там может быть null и когда форма создается в дизайнере студии, поскольку дизайнер студии устанавливает это свойство довольно поздно (впрочем, он и не может раньше).
Почему поздно? Очень даже вовремя. Просто ты строишь дизайн своего кода неверно. Только и всего. У МС тонна контролов и ни одих не занимается подобной еруной.
ЗЫ
Ты не высасывай пробему из пальца. Ты лучше опиши случай в котором ты не видишь иного выхода.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Igor Trofimov, Вы писали:
VD>>Еще раз говорю. Описывай задачу.
iT>Задача все та же — точно определить, находится ли форма в DesignTime или в RunTime. Из любого метода/конструктора. Предположим, что в самой проге (RunTime) — никаких дизайнерских штучек нет. То есть речь идет о вариантах VisualStudio / Application
Это не задача. Это уже ее решение. У тебя вообще паталогическое стремление решать задачи одним, зачастую неверным, способом.
Опиши конкретный пример.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Это не задача. Это уже ее решение. У тебя вообще паталогическое стремление решать задачи одним, зачастую неверным, способом.
Какое же это решение? А.. ну я так и знал, определять DesignTime/Runtime — порочная практика
Ну ладно, придумаю более конкретно — форма должна загружать свой размер из некоторого хранилища настроек. Но только в RunTime (думаю, это достаточно очевидно).
VD>Так не надо делать в конструкторе вещи которые там делать не надо. Сайт назначается после создания объекта, т.п. после того как конструктор уже отработал. Процес же конструирования еще идет. Перенеси нужный тебе код в место где сайт уже точно есть.
А вот тут начинается совсем интересно. Потому чито последовательность вызова всех стандартных событий — OnLoad, BeginInit/EndInit, вызовов конструкторов и назначения ISite и проч. — достаточно неопределенная вещь.
По крайней мере в развитой иерархии наследования форм/контролов. И такого места как "конструирование закончено" — еще поискать надо.
VD>Почему поздно? Очень даже вовремя. Просто ты строишь дизайн своего кода неверно. Только и всего. У МС тонна контролов и ни одих не занимается подобной еруной.
Да, да, конено Если проблема не решается в текущей версии — значит, у вас проблема в дизайне. Плавали, знаем. Generic'ов уже дождались, поглядим, что будет дальше.
Здравствуйте, Igor Trofimov, Вы писали:
iT>А вот тут начинается совсем интересно. Потому чито последовательность вызова всех стандартных событий — OnLoad, BeginInit/EndInit, вызовов конструкторов и назначения ISite и проч. — достаточно неопределенная вещь. iT>По крайней мере в развитой иерархии наследования форм/контролов. И такого места как "конструирование закончено" — еще поискать надо.
Все четко определено. Последовательность следущая:
Вариант 1. Контрол появляется в первый раз:
1. Создается класс (вызывается его конструтор).
2. Назначается сайт.
Варинт 2. Класс загружается дизайнером из состояния сериализованного в код:
1. Создается класс (вызывается его конструтор).
2. Назначается сайт.
3. Вызывается BeginInit.
4. Вызывается EndInit.
VD>>Почему поздно? Очень даже вовремя. Просто ты строишь дизайн своего кода неверно. Только и всего. У МС тонна контролов и ни одих не занимается подобной еруной.
iT>Да, да, конено Если проблема не решается в текущей версии — значит, у вас проблема в дизайне. Плавали, знаем. Generic'ов уже дождались, поглядим, что будет дальше.
Причем тут дженерики?
Возможно. Что-то в данном случае не очевидно. И что-то можно было бы сделать лучше (в самой компонентной модели), но какое это имеет отношение к откровенному и ненужному хаку?
Или в отсуствии дженериков ты внутри кода занимаешся его декомпиляцией чтобы работать с элементами кллекций? (если уж прбегать к аналогиям)
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Igor Trofimov, Вы писали:
iT>Ну ладно, придумаю более конкретно — форма должна загружать свой размер из некоторого хранилища настроек. Но только в RunTime (думаю, это достаточно очевидно).
О, блин! И из-за этой фигни надо было стэк-фрэйм изучить? Я фигею, дарагая редакция...
Добавь вот этот код в форму и полючуйся на результат:
protected override void OnCreateControl()
{
base.OnCreateControl ();
ISite site = Site;
if (site == null || !site.DesignMode)
{
MessageBox.Show("Мы в рантайме. Выставляем размры в 200 на 50.");
this.Size = new Size(200, 50);
}
else
MessageBox.Show("Мы в дизайнере");
}
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>О, блин! И из-за этой фигни надо было стэк-фрэйм изучить? Я фигею, дарагая редакция...
Ладно, согласен, конкретно это можно и на позднем этапе сделать.
Но скажи мне — ты разве никогда не производишь каких-то действий именно в конструкторе формы? Да и не только в конструкторе — огромная куча методов будет ошибаться в определении DesignTime'а твоим способом. Это и конструктор, и CreateParams и всякие OnPaint,OnResize, и все конструкторы контролов, которые лежат на форме, и их BeginInit/EndInit и set'теры всех их свойств, сериализованных в код.
Все они будут говорить "Мы в RunTime!" и это будет неправдой.
Разве никогда не добавляешь на форму динамически какие-то контролы? Где это правильнее всего делать? Часто — именно в конструкторе, рядышком с InitializeControl, правильно? Вот у тебя будет радости, когда это все в DesignTime добавится...
В общем, я считаю, что лучше один раз написать абсолютно надежную проверку и сохранить результат в статическом поле каком-нибудь, чем пользоваться этим ненадежным, зато на 100% стандартным способом, который привел ты и потом гадать — где этот способ сработает, а где нет. А то и глюки еще ловить — ах, отчего дизайнер слетел, ах, это потому что не смогли понять, что в дизайнере находимся.
VD>Вариант 1. Контрол появляется в первый раз: VD>1. Создается класс (вызывается его конструтор). VD>2. Назначается сайт. VD>Варинт 2. Класс загружается дизайнером из состояния сериализованного в код: VD>1. Создается класс (вызывается его конструтор). VD>2. Назначается сайт. VD>3. Вызывается BeginInit. VD>4. Вызывается EndInit.
Ой, как все просто и адназначна! А в курсе, что у контрола может несколько раз меняться имя? Что BeginInit/EndInit может вызываться несколько раз? Что может вызваться EndInit/OnLoad тогда, когда у контрола, например, уже есть родитель (панель какая-нибудь), а у нее самой — нету, появится позже. Что OnLoad может произойти до того, как контрол получит имя, а может — после.
То есть это все тоже вполне четко определено. И совершенно понятно, отчего это происходит. Но легче от этого не становится.
Все очень просто, пока мы берем голую форму и одну кнопку на ней.
VD>Причем тут дженерики?
При том, что когда-то тоже многие говорили, что то не нужно, это не нужно... А потом оказывалось, что очень даже нужно.
VD>И что-то можно было бы сделать лучше (в самой компонентной модели), но какое это имеет отношение к откровенному и ненужному хаку?
Увы, нужному. И почему хаку? Давайте тогда и CAS хаком назовем, раз стек трейсит, и Serialization, раз к приватным членам доступ имеет. Вопрос терминологии. Суть в том, что этот самый "хак" — работает надежно и всегда, в отличие от проверки ISite.
VD>Или в отсуствии дженериков ты внутри кода занимаешся его декомпиляцией чтобы работать с элементами кллекций? (если уж прбегать к аналогиям)
В отсуствии дженериков кое-кто и код генерит (я не говорю про те случаи, когда это не заменяется generic'ами), что однозначно более плохое решение. А кто-то — с тормозныими и нетипизированными коллекциями работает, что тоже не очень здорово.
.
