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

AVK>>Зачем так сложно? Достаточно использовать твой контрол в кастомном UITypeEditor и все, приплыли.

iT>Ну, это и есть часть дизайнера.

Вот именно.

iT> Нда, тут фокус со стеком не пройдет. Хреново.

Вот тебе и причина почему хаки это очень очень плохо.

iT> Правда я с трудом себе представляю контрол достаточно сложный для того, чтобы ему нужна была особая инициализация и достаточно универсальный для того, чтобы его использовать и в элементе дизайнера и в целевом приложении.

Вам примеров? Их есть у меня. Сцинтилловская обертка наша использует саму себя для редактирования свойства Text. TreeView использует самого себя для редактирования свойства Nodes. Про PropertyGrid думаю ты тоже не забыл. Ну как, достаточно примеров?

iT>Хотя... Если например, делать дизайнер форм для корпоративной системы — то там наверняка захочется применить и какие-то стандартные для системы контролы — причем тоже иногда в DesignTime, иногда в Runime, но из дизайнера. Ну, тут уж я вообще не знаю тогда, как выкручиваться, если надо определить DesignTime

Выкручиваться очень просто, тут уже говорили как — выносить дизайнерский код во внешние классы, не работающие в рантайме. А если их много то лучше даже в отдельную сборку, ибо нефиг занимать память в рантайме дизайнтаймным кодом. Да и отлаживать проще.

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

iT>Только это не всегда работает. Например, не работает для конструкторов базовых форм.
iT>Более точно можно определить, трассируя стек вызова на наличие объектов, реализующих IDesignerHost.
iT>Могу дать кусок кода.

IDesignerHost вполне может обнаружится и в рантайме.

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

MG>Чтобы в PropertyGrid можно было подсунуть свой ServiceProvider, достаточно переопределить метод GetService у PropertyGrid.

Component.GetService:

protected virtual object GetService(Type service)
{
    ISite site1 = this.site;
    if (site1 != null)
    {
        return site1.GetService(service);
    }
    return null;
}

Так что никакой разницы, но имхо с Site более правильно.

P.S. — никаких глюков не обнаружено, все сервисы нормально гридом зовутся, даже те что в студии не используются.

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

VD>>О, блин! И из-за этой фигни надо было стэк-фрэйм изучить? Я фигею, дарагая редакция...
iT>Ладно, согласен, конкретно это можно и на позднем этапе сделать.
Скажем так, в подавляющем большинстве случаев это можно делать на позднем этапе.

iT>В общем, я считаю, что лучше один раз написать абсолютно надежную проверку и сохранить результат в статическом поле каком-нибудь
Нельзя кешировать. В какой-нибудь среде вполне может быть фича "Try dialog" (вроде в VB было такое когда-то), и дизайн-тайм/ран-тайм вполне может переключаться на лету. Конечно, скорее всего будет создан новый объект такого типа, и ты можешь кэшировать на уровне объекта, но кто знает?

iT>, чем пользоваться этим ненадежным, зато на 100% стандартным способом, который привел ты и потом гадать — где этот способ сработает, а где нет.
Гадать не надо, это сработает везде, кроме конструкторов.

iT>А то и глюки еще ловить — ах, отчего дизайнер слетел, ах, это потому что не смогли понять, что в дизайнере находимся.
Тестировать надо

Вообще говоря, этот момент можно было бы сделать поудобнее. Например, дизайнер мог бы создать неинициализированный объект (без вызова конструктора) используя FormatterServices.GetSafeUninitializedObject, затем выставить ему сайт, а уж затем ручками позвать конструктор. Всё равно через рефлекшн работает. Правда, если пользователь переопределит свойство Site, он будет иметь дело с "нехорошим" объектом. Или предоставить класс DesignerServices и статический метод bool IsComponentBeingDesigned(IComponent component). Варианты есть

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

O>>Гадать не надо, это сработает везде, кроме конструкторов.
iT>Конструкторов "самой конкретной" формы! (Думаю, понятно, о чем я)
iT>И всего, что из них вызывается! А это может быть очень много — все контролы, их свойства и т.п. И это на каждом уровне иерархии формы.

Блин, да, в VS.NET конструктор формы (если она унаследована от Form) вообще никогда не вызывается в дизайн-тайме, так как твой класс никогда не создается. Так что делай в нем все что хочешь — это будет вызвано только в рантайме. Вот только заклдываться на VS.NET не очень корректно. Хотя без тестирования врдли можно делать контролы для разных сред.

O>>Вообще говоря, этот момент можно было бы сделать поудобнее.
iT>О том и речь..

Не, речь о необходимости, а точнее о допустимости хаков в коде серьезного программиста. А кривостей у МС или кого-нить другого будет еще тонна.

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

iT>Да не при чем тут "хак", как ты это называешь. Это все к твоему "перемести в подходящее место".

Точнее в не подходящее. И чтобы хоть как-то заработало занимаешся кул-хацкерством.

VD>>Я говорил? Ну, и если нет, то какое они имеют отношение к данному вопросу? Заведи отдельную тему... поговорим.

iT>Самое прямое. Ведь мы же говорим (я, по крайней мере, стараюсь) о том, что считать нужным, а что ненужным.

Ты уже второй раз демонстрируешь, что вместо того чтобы решать реальные проблемы ты пытаешся создавать проблемы и каое-как их решать. Получается раком и совершенно бессмысленно.

iT>Ты уверяешь, что всегда можно обойтись и без проверки на DesignTime в конструкторе и во всем, что из него может вызваться. А я не хочу обходиться.

Ну, хозяин барин. Я уже понял, что качество ПО тебя не трогает. Нравится кулхацкерить — кулхацкери, только потом не нужно кричать по всем форумам, что что-то кривае. Это руки кривые.

iT> Ну неужели не видно такой простой аналогии с историей возникновения java и generic'ов?

Не. В упор не видно.

И более того. Любая обратная аналогия не доказуема и их не стоит использовать для размышелий.

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

AVK>>Именно так . Дизайнер создает экземпляр базового класса, а не того который ты дизайнишь. Поэтому, кстати, невозможно наследовать форму от абстрактного класса.

iT>Вот именно, что базового. Который вовсе не обязан быть Form.

Блин, да, в VS.NET конструктор формы (если она унаследована от Form) вообще никогда не вызывается в дизайн-тайме

Внимательнее читай.

iT>Кстати, любопытно, что приватность конструктора при этом дизайнеру не мешает (слава богу).

Так рефлекшен ведь.

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

O>Основанием для любых хаков является требование к программе и необходимость её работоспособности в заданные сроки в заданных условиях. Можно сколько угодно говорить, что проверять стек "не кошерно", но если надо быстро сделать проверку на дизайн-тайм в конструкторе — это подходящий способ.

И все таки хотелось услышать про реальную задачку в которой требуется проверка на дизайн-тайм в конструкторе.

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

O>>Основанием для любых хаков является требование к программе и необходимость её работоспособности в заданные сроки в заданных условиях. Можно сколько угодно говорить, что проверять стек "не кошерно", но если надо быстро сделать проверку на дизайн-тайм в конструкторе

VD>Таки мы услышим разумное обяснение почему проверка обязана быть в конструкторе, а не где-то еще?
Предыдущий пост был абстрактно, а не по конкретной проблеме Извини, что не уточнил. Я уже писал, что в подавляющем большинстве случаев такой хак не нужен. Однако, например, если ты посмотришь на винформовский NotifyIcon (FW 1.1), то увидишь, что там применяется другой, но хак. Там делается дизайнер, который выставляет свойство видимости после отработки конструктора, чтобы в режиме дизайна иконка не появлялась в трее. Лучше так или не лучше — судить не берусь.

O>> — это подходящий способ.
VD>Хак может быть подходящим способом только при условии, что другими средствами задача не решаема.
Конечно.

VD>Ни ты, ни Igor Trofimov не привели ни одного примера где такая необходимость прослеживалась бы. А посему вы занимаетесь перемалыванием воздуха.
Не надо ярлыков. Мы рассуждаем о прекрасном — о хаках Вчера вот с удовольствием ковырял DOS-программу 92го года выпуска, на уровне ассемблера — надо было структуру базы расковырять. Получил бешенное удовольствие!

O>>Не будем забывать про то, что некоторые всё-таки работают по управляемому процессу, а не "как шибануло вечером под пиво"
VD>Управляемостью процесса у вас и не пахнет. Вам продемонстировали как решаются проблема, а вы заниматесь бессмысленными отговорками.
Опять лепишь стикеры... Если ты участовал в проектах "по уму" — должен понимать, о чём идёт речь. Если нет — тогда даже чтение умных книжек не поможет...

VD>В обещем, причем тут веремя я понять так и не смог. Вы утверждаете, что есть какие-то непреодолимые проблемы. Привести их пример вы не в состоянии. О чем собственно тогда речь?
Не бывает непреодолимых проблем, бывает отсутствие времени на их решение. Ну вот срочно например надо поправить багу в продукте-выпускаемом-завтра, чтобы некий компонент стал "хорошо" вести себя в дизайнере. На перепроектирование времени нет — придётся лепить "заплатку". Или другой пример, есть уже выпущенный компонент, тут находят уже багу в поведении в ран-тайм, но связанную с поддержкой времени дизайна. Добавить ISupportInitialize — не самое лучшее решение, потому что это потребует открытия всех форм в дизайнере, фейкового изменения, чтобы код пересериализовался с учётом этого интерфейса, и перекомпиляции. Простая замена пофиксенной компоненты ничего не даст. Иначе говоря — breaking change, что не всегда приемлимо.

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

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

Зачем так сложно? Достаточно использовать твой контрол в кастомном UITypeEditor и все, приплыли.

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

O>Предыдущий пост был абстрактно, а не по конкретной проблеме Извини, что не уточнил. Я уже писал, что в подавляющем большинстве случаев такой хак не нужен. Однако, например, если ты посмотришь на винформовский NotifyIcon (FW 1.1), то увидишь, что там применяется другой, но хак. Там делается дизайнер, который выставляет свойство видимости после отработки конструктора, чтобы в режиме дизайна иконка не появлялась в трее. Лучше так или не лучше — судить не берусь.

ИМХО значительно лучше и никакой это не хак, поскольку прием опирается на вобщем то документированные вещи.

O>Не бывает непреодолимых проблем, бывает отсутствие времени на их решение. Ну вот срочно например надо поправить багу в продукте-выпускаемом-завтра, чтобы некий компонент стал "хорошо" вести себя в дизайнере. На перепроектирование времени нет — придётся лепить "заплатку".

В данном случае имхо налепливание такой заплаты вполне сопоставимо по затратам времени с заменой дизайн-тайм зависимой инициализации в конструкторе на инициализацию по требованию.

Как узнать, мой компонет сейчас в дизайне или в выполняемом приложении?


Спасибо.

Здравствуйте, Аноним, Вы писали:

А>Как узнать, мой компонет сейчас в дизайне или в выполняемом приложении?

Через Component.Site.DesignMode

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

TK>Здравствуйте, Аноним, Вы писали:

А>>Как узнать, мой компонет сейчас в дизайне или в выполняемом приложении?

TK>Через Component.Site.DesignMode
В рантайме Site можеь быть равен null, тачто будь осторожен!

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

TK>Здравствуйте, Аноним, Вы писали:

А>>Как узнать, мой компонет сейчас в дизайне или в выполняемом приложении?

TK>Через Component.Site.DesignMode

Спасибо.


Хотя еще вопрос, как вообще сделать так чтобы компонент сделал основное вычисление после того как
установлены все его свойства. В Component Designer generated code все свойства устанавливаются поочереди (в алфавитном порядке вроде.),и свойство активации может быть и вначале.
Как узнать что все свойства установлены и пора сто-то сделать автоматически?

Я конечно смогу запустить процедуру пересчета, Но хотелось бы узнать как это сделать автоматом.

Дело в том что работу компонента можно посмотреть и в DesignMode. естьсвойство Activate которое нужно установить в true и результирующие ReadOnly property заполнятся.

При старте формы Activate если я оставил его в true активируется первым, но неработает так как неустановлены
другие свойства... (вроде понятно рассказал?)

что делать?

Здравствуйте, <Аноним>, Вы писали:

А>что делать?

ISupportInitialize allows controls to optimize for multiple sets to properties. As a result, you can initialize co-dependent properties or batch set multiple properties at design time.

Call the BeginInit method to signal the object that initialization is starting. Call the EndInit method to signal that initialization is complete.

Hello,
>
> Хотя еще вопрос, как вообще сделать так чтобы компонент сделал основное вычисление после того как
> установлены все его свойства.

для этого есть интерфейс ISupportInitialize. Его нужно реализовать

Здравствуйте, <Аноним>, Вы писали:

А>Как узнать что все свойства установлены и пора сто-то сделать автоматически?
Тебе просто необходимо реализовать интерфейс ISupportInitialize

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

TK>>Через Component.Site.DesignMode
VP>В рантайме Site можеь быть равен null, тачто будь осторожен!

С вероятностью 99.9999999999999999% .

TK>Через Component.Site.DesignMode

Только это не всегда работает. Например, не работает для конструкторов базовых форм.
Более точно можно определить, трассируя стек вызова на наличие объектов, реализующих IDesignerHost.
Могу дать кусок кода.

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

TK>>>Через Component.Site.DesignMode
VP>>В рантайме Site можеь быть равен null, тачто будь осторожен!

VD>С вероятностью 99.9999999999999999% .

Что то ты больно крутую вероятность забацал. У меня к примеру в одном из приложений он совсем не null. Не думаю что в мире свуществует 10000000000000000 приложений, написанных на дотнете и использующих компоненты.

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

iT>Только это не всегда работает. Например, не работает для конструкторов базовых форм.
iT>Более точно можно определить, трассируя стек вызова на наличие объектов, реализующих IDesignerHost.
iT>Могу дать кусок кода.

А еще более точно занимаясь дизасемблированием кода.

Такие "подходы" являются ошибками дизайна и часто выливаются в кучу геморроя в будущем.

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

VD>>С вероятностью 99.9999999999999999% .

AVK>Что то ты больно крутую вероятность забацал. У меня к примеру в одном из приложений он совсем не null. Не думаю что в мире свуществует 10000000000000000 приложений, написанных на дотнете и использующих компоненты.

А у меня вероятность в компонентах. Ты вот сам говоришь "в одном из...".

Кстати, зачем тебе нужен самопальный сайт если ты не делаешь дизайнер?

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

iT>>Только это не всегда работает. Например, не работает для конструкторов базовых форм.
iT>>Более точно можно определить, трассируя стек вызова на наличие объектов, реализующих IDesignerHost.
iT>>Могу дать кусок кода.

AVK>IDesignerHost вполне может обнаружится и в рантайме.

Во-во. Уж если выпендриваться, то перегружать свойство Site и т.п. А так то зачем?

AVK>IDesignerHost вполне может обнаружится и в рантайме.
Ну, это если твоя система содержит дизайнер.
А это тоже можно отдельно проверить.

AVK>>IDesignerHost вполне может обнаружится и в рантайме.
VD>Во-во. Уж если выпендриваться, то перегружать свойство Site и т.п.

И что там написать

VD>А еще более точно занимаясь дизасемблированием кода.
VD>Такие "подходы" являются ошибками дизайна и часто выливаются в кучу геморроя в будущем.

Отлично! Может у тебя есть другой рецепт выяснения, находится ли форма в design-time?
Или может "если это нужно знать, значит, ошибка в дизайне"?

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

TK>Hello,
>>
>> Хотя еще вопрос, как вообще сделать так чтобы компонент сделал основное вычисление после того как
>> установлены все его свойства.

TK>для этого есть интерфейс ISupportInitialize. Его нужно реализовать


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



спасибо.

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

VD>Кстати, зачем тебе нужен самопальный сайт если ты не делаешь дизайнер?

Чтобы в PropertyGrid можно было подсунуть в рантайме свой ServiceProvider. Сайт притом не самопальный, а вполне себе родной, фреймворковский.

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

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

VD>>Кстати, зачем тебе нужен самопальный сайт если ты не делаешь дизайнер?

AVK>Чтобы в PropertyGrid можно было подсунуть в рантайме свой ServiceProvider. Сайт притом не самопальный, а вполне себе родной, фреймворковский.

Чтобы в PropertyGrid можно было подсунуть свой ServiceProvider, достаточно переопределить метод GetService у PropertyGrid. Иначе возможны траблы, какие не помню, но то что они были это точно. Все компоненты находились в дизайне т.е. имели нормальный сайт и полноценный набор сервисов в ServiceProvider, до нужного сервиса PropertyGrid не хотел достукиваться, изучил всю линеку объектов у которых он просил.
В итоге сутки искал причину, оказалось что-то связаное IComponentChangeService или IDesignerEventService, точнее не могу вспомнить. Кстати как потом обнаружил "Сама VS" подставляет свой ServiceProvider точно таким же образом, см Microsoft.VisualStudio.PropertyBrowser.PropertyGridHolder.

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

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

MG>>Чтобы в PropertyGrid можно было подсунуть свой ServiceProvider, достаточно переопределить метод GetService у PropertyGrid.

AVK>Component.GetService:
AVK>

AVK>protected virtual object GetService(Type service)
AVK>{
AVK>    ISite site1 = this.site;
AVK>    if (site1 != null)
AVK>    {
AVK>        return site1.GetService(service);
AVK>    }
AVK>    return null;
AVK>}
AVK>

AVK>Так что никакой разницы, но имхо с Site более правильно.

AVK>P.S. — никаких глюков не обнаружено, все сервисы нормально гридом зовутся, даже те что в студии не используются.

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

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

iT>Отлично! Может у тебя есть другой рецепт выяснения, находится ли форма в design-time?
iT>Или может "если это нужно знать, значит, ошибка в дизайне"?

Опиши проблему — найдем решение или укажем на ошибку.

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

iT>И что там написать

Зависит от задачи.

Еще раз говорю. Описывай задачу.

Здравствуйте, <Аноним>, Вы писали:

А>Help я прочитал, но так и не понял как его реализовать..
А>Вы не мудрите, вы пальцем покажите...
А>Обьясние если можно на пальцах и с маленьким примером.

Нда. Может проше книгу каку по языку прочесть или стандарт?

В краце: береш компонент в котором нужно делать пост-инициализационные действия. Встаешь в его список реализуемых интерфейсов... Пишеш "ISupportInitialize" и нажимаешь TAB. Студия докинывает пустышки метдов.

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

AVK>Чтобы в PropertyGrid можно было подсунуть в рантайме свой ServiceProvider. Сайт притом не самопальный, а вполне себе родной, фреймворковский.

PropertyGrid — это уже дизайнер.

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

AVK>>Чтобы в PropertyGrid можно было подсунуть в рантайме свой ServiceProvider. Сайт притом не самопальный, а вполне себе родной, фреймворковский.

VD>PropertyGrid — это уже дизайнер.

Ну это как сказать.

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

AVK>IDesignerHost вполне может обнаружится и в рантайме.
А это не означает, что компонент всё-таки в дизайне, несмотря на то, что система в рантайме?

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

AVK>>IDesignerHost вполне может обнаружится и в рантайме.
O>А это не означает, что компонент всё-таки в дизайне, несмотря на то, что система в рантайме?

Не обязательно. Тут вопрос встает зачем вобще понадобилось обосабливать дизайнтайм.

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

AVK>>>IDesignerHost вполне может обнаружится и в рантайме.
O>>А это не означает, что компонент всё-таки в дизайне, несмотря на то, что система в рантайме?

AVK>Не обязательно. Тут вопрос встает зачем вобще понадобилось обосабливать дизайнтайм.
Бывает нужно. Теоретически можно всё решить кастомными дизайнерами, но ради того, чтобы несколько поиному отрисоваться городить дизайнер не хочется. У меня, например, LayoutPanel в дизайне подсвечивает зоны, чтобы видно было раскладку.

VD>Еще раз говорю. Описывай задачу.

Задача все та же — точно определить, находится ли форма в 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 и когда форма создается в дизайнере студии, поскольку дизайнер студии устанавливает это свойство довольно поздно (впрочем, он и не может раньше).

Почему поздно? Очень даже вовремя. Просто ты строишь дизайн своего кода неверно. Только и всего. У МС тонна контролов и ни одих не занимается подобной еруной.

ЗЫ

Ты не высасывай пробему из пальца. Ты лучше опиши случай в котором ты не видишь иного выхода.

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

VD>>Еще раз говорю. Описывай задачу.

iT>Задача все та же — точно определить, находится ли форма в DesignTime или в RunTime. Из любого метода/конструктора. Предположим, что в самой проге (RunTime) — никаких дизайнерских штучек нет. То есть речь идет о вариантах VisualStudio / Application

Это не задача. Это уже ее решение. У тебя вообще паталогическое стремление решать задачи одним, зачастую неверным, способом.

Опиши конкретный пример.

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'ов уже дождались, поглядим, что будет дальше.

Причем тут дженерики?

Возможно. Что-то в данном случае не очевидно. И что-то можно было бы сделать лучше (в самой компонентной модели), но какое это имеет отношение к откровенному и ненужному хаку?

Или в отсуствии дженериков ты внутри кода занимаешся его декомпиляцией чтобы работать с элементами кллекций? (если уж прбегать к аналогиям)

Здравствуйте, 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("Мы в дизайнере");
        }

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'ами), что однозначно более плохое решение. А кто-то — с тормозныими и нетипизированными коллекциями работает, что тоже не очень здорово.

O>Гадать не надо, это сработает везде, кроме конструкторов.
Конструкторов "самой конкретной" формы! (Думаю, понятно, о чем я)
И всего, что из них вызывается! А это может быть очень много — все контролы, их свойства и т.п. И это на каждом уровне иерархии формы.

O>Вообще говоря, этот момент можно было бы сделать поудобнее.
О том и речь..

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

O>Вообще говоря, этот момент можно было бы сделать поудобнее.

Согласен.

O> Например, дизайнер мог бы создать неинициализированный объект (без вызова конструктора) используя FormatterServices.GetSafeUninitializedObject, затем выставить ему сайт, а уж затем ручками позвать конструктор.

А вот с этим нет. Это хаки, а их лучше избегать любой ценой.

Я бы сделал так. Ввел бы просто заставли рантайм-подсистему тоже назначать сайт. Но рантаймный сайт не должен ничего делать кроме как коворить, что мы в рантайме.

Еще как вариант назначать вместо сайта null.

O> Всё равно через рефлекшн работает.

А вот это уже тебе никто не гарантирует.

O> Правда, если пользователь переопределит свойство Site, он будет иметь дело с "нехорошим" объектом. Или предоставить класс DesignerServices и статический метод bool IsComponentBeingDesigned(IComponent component). Варианты есть

Статический?

ЗЫ

В общем, отсуствие продуманной схемы у МС не является основанием для хаков.

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

iT>Ладно, согласен, конкретно это можно и на позднем этапе сделать.

Думаю, что 99% других случаев тоже имеют решение. А на тот 1% что неудастся можно просто забить.

iT>Но скажи мне — ты разве никогда не производишь каких-то действий именно в конструкторе формы? Да и не только в конструкторе — огромная куча методов будет ошибаться в определении DesignTime'а твоим способом. Это и конструктор, и CreateParams и всякие OnPaint,OnResize, и все конструкторы контролов, которые лежат на форме, и их BeginInit/EndInit и set'теры всех их свойств, сериализованных в код.

iT>Все они будут говорить "Мы в RunTime!" и это будет неправдой.

Не забивай себе голову ерундой. Все кроме конструктора будет иметь доступ к сайту, так как он назначается сразу после выхода из конструктора. Так что пиши код в режиме отложенной реакции и все будет ОК. Собственно весь код МС на то и рассчитан.

BeginInit и EndInit тоже всегда вызваются после вызова конструктора, так что тоже из них всегда можно получить доступ к сайте.


iT>Разве никогда не добавляешь на форму динамически какие-то контролы? Где это правильнее всего делать? Часто — именно в конструкторе, рядышком с InitializeControl, правильно? Вот у тебя будет радости, когда это все в DesignTime добавится...

Ты уж если задаещь не риторический вопрос, то давай на него ответить. ОК?

Тот же OnCreateControl позволяет решить 99% проблем формы. Нля обычных контролов кстати тоже, но для них вообще есть шатные BeginInit/EndInit.

iT>В общем, я считаю, что лучше один раз написать абсолютно надежную проверку и сохранить результат в статическом поле каком-нибудь, чем пользоваться этим ненадежным, зато на 100% стандартным способом, который привел ты и потом гадать — где этот способ сработает, а где нет. А то и глюки еще ловить — ах, отчего дизайнер слетел, ах, это потому что не смогли понять, что в дизайнере находимся.

В общем, не придумывай на ходу. Если есть еще "нерешаемые проблемы" то излагай — решим.

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

iT>Ой, как все просто и адназначна!

Да. Вот так.

iT> А в курсе, что у контрола может несколько раз меняться имя?

Это отдельный вопрос не связанный с вопросом инициализации никаким боком.

iT> Что BeginInit/EndInit может вызываться несколько раз?

Нет. Это инициализация.

iT> Что может вызваться EndInit/OnLoad тогда, когда у контрола, например, уже есть родитель (панель какая-нибудь), а у нее самой — нету, появится позже.

И причем тут это?


iT> Что OnLoad может произойти до того, как контрол получит имя, а может — после.

Контрол получт имя вместе ссайтом. А изменение имени приведет к вызову дизйн-тайм-события. Если тебе нужно, отлавливай его.

iT>То есть это все тоже вполне четко определено. И совершенно понятно, отчего это происходит. Но легче от этого не становится.

Ты можешь четко объяснить причем тут твой хак с чтением стэк-фрейма? Или тебе просто хочется высказаться без определенной темы?

iT>Все очень просто, пока мы берем голую форму и одну кнопку на ней.

Все очень просто если разбираться в конкретных случаях, и не заниматься кул-хацкерством. И очень сложно если вместо решения конкретных и детерминированных задач начинать вопить что все плохо и жизнь не удалась с самого утра.

VD>>Причем тут дженерики?
iT>При том, что когда-то тоже многие говорили, что то не нужно, это не нужно... А потом оказывалось, что очень даже нужно.

Я говорил? Ну, и если нет, то какое они имеют отношение к данному вопросу? Заведи отдельную тему... поговорим.

VD>>И что-то можно было бы сделать лучше (в самой компонентной модели), но какое это имеет отношение к откровенному и ненужному хаку?

iT>Увы, нужному.

Убедительных аргументов в его необходимости я не увидил. Вместо них какая-то истерика.

В общем, показывай примеры убеждающие в его необходимости. Иначе отсуствует даже предмет обсуждения.

iT> И почему хаку? Давайте тогда и CAS хаком назовем, раз стек трейсит, и Serialization, раз к приватным членам доступ имеет. Вопрос терминологии. Суть в том, что этот самый "хак" — работает надежно и всегда, в отличие от проверки ISite.

iT>В отсуствии дженериков кое-кто и код генерит (я не говорю про те случаи, когда это не заменяется generic'ами), что однозначно более плохое решение. А кто-то — с тормозныими и нетипизированными коллекциями работает, что тоже не очень здорово.

Создавай отдельную тему — обсудим.

VD>Блин, да, в VS.NET конструктор формы (если она унаследована от Form) вообще никогда не вызывается в дизайн-тайме, так как твой класс никогда не создается.

Sure?

VD>BeginInit и EndInit тоже всегда вызваются после вызова конструктора, так что тоже из них всегда можно получить доступ к сайте.

Увы, увы, но это не совсем так. Они могут вызываться во время работы конструктора формы. Т.е. до того, как дизайнер пропишет ISite.

VD>Ты можешь четко объяснить причем тут твой хак с чтением стэк-фрейма? Или тебе просто хочется высказаться без определенной темы?

Да не при чем тут "хак", как ты это называешь. Это все к твоему "перемести в подходящее место".

VD>Я говорил? Ну, и если нет, то какое они имеют отношение к данному вопросу? Заведи отдельную тему... поговорим.

Самое прямое. Ведь мы же говорим (я, по крайней мере, стараюсь) о том, что считать нужным, а что ненужным.
Ты уверяешь, что всегда можно обойтись и без проверки на DesignTime в конструкторе и во всем, что из него может вызваться. А я не хочу обходиться. Ну неужели не видно такой простой аналогии с историей возникновения java и generic'ов?

VD>Создавай отдельную тему — обсудим.

Ок

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

iT>Увы, увы, но это не совсем так. Они могут вызываться во время работы конструктора формы. Т.е. до того, как дизайнер пропишет ISite.

Чушь не говори. ISupportInitialize или работает или нет. Для любого контрола ISupportInitialize вызывается после подключения к нему сайта. Пинять на форуме тут не нужно. Она опять же не причем.

ЗЫ

Научсь отделять проблемы и решать их по отдельности. Иначе если навалить в кучу ворох даже самых маленьких проблем, ришить их не удастся, так как в голове будет каша.

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

VD>>Блин, да, в VS.NET конструктор формы (если она унаследована от Form) вообще никогда не вызывается в дизайн-тайме, так как твой класс никогда не создается.

iT> Sure?

В отличии от тебя.

Дизайнер форм в студии создает базовый класс (обычно Form), а контролы грузит сам в режиме интерпретации.

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

VD>>Блин, да, в VS.NET конструктор формы (если она унаследована от Form) вообще никогда не вызывается в дизайн-тайме, так как твой класс никогда не создается.

iT> Sure?

Именно так . Дизайнер создает экземпляр базового класса, а не того который ты дизайнишь. Поэтому, кстати, невозможно наследовать форму от абстрактного класса.

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

VD>Дизайнер форм в студии создает базовый класс (обычно Form), а контролы грузит сам в режиме интерпретации.
Интересно а чем это вызвано и в чем проблема???? Почему нельзя вызвать конструктор конкретной формы?????

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

S> Интересно а чем это вызвано и в чем проблема???? Почему нельзя вызвать конструктор конкретной формы?????

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

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

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

S>> Интересно а чем это вызвано и в чем проблема???? Почему нельзя вызвать конструктор конкретной формы?????

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

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

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

Возможно ты не внимально меня читал. Еще раз повторяю, что класс может находиться в польностью нерабочем состоянии. Так что загружать у него можно только код сгенерированный дизайнером же. Иначе МС будет завален вопросом "почему у меня не открывается форма?".

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

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

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

VD>Возможно ты не внимально меня читал. Еще раз повторяю, что класс может находиться в польностью нерабочем состоянии. Так что загружать у него можно только код сгенерированный дизайнером же. Иначе МС будет завален вопросом "почему у меня не открывается форма?".
Эх мало я занимался компоненто строением. Поверю тебе на слово. В них есть большое зерно истины.

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

VD>>Дизайнер форм в студии создает базовый класс (обычно Form), а контролы грузит сам в режиме интерпретации.
S> Интересно а чем это вызвано и в чем проблема???? Почему нельзя вызвать конструктор конкретной формы?????

Потому что базовый класс обычно скомпилирован и его не надо пересобирать на каждый чих при редактировании.

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

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

VD>>>Дизайнер форм в студии создает базовый класс (обычно Form), а контролы грузит сам в режиме интерпретации.
S>> Интересно а чем это вызвано и в чем проблема???? Почему нельзя вызвать конструктор конкретной формы?????

AVK>Потому что базовый класс обычно скомпилирован и его не надо пересобирать на каждый чих при редактировании.
Я не большой специалист в компоненто строении поэтому и спрашиваю. Реально в дизайн тайме меняются только свойства компонентов и вроде о пересборке никакой речи не идет, как и при динамическом изменении свойст в рантайме, только отрисовка и доступ к событиям в этом случае будут другими.

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

AVK>>Потому что базовый класс обычно скомпилирован и его не надо пересобирать на каждый чих при редактировании.
S> Я не большой специалист в компоненто строении поэтому и спрашиваю. Реально в дизайн тайме меняются только свойства компонентов и вроде о пересборке никакой речи не идет, как и при динамическом изменении свойст в рантайме, только отрисовка и доступ к событиям в этом случае будут другими.

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

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

AVK>Ты не забыл о том что речь идет о форме? Вот форма в процессе редактирования может менятся как угодно.
Прошу прощения еще не вдавался в тонкости, и выражаю больше свое видение чем знания.
Но у формы мняются ведь только свойства и набор подчиненных контролов (компонентов) с которыми связаны на подобие Notification.

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

AVK>>Ты не забыл о том что речь идет о форме? Вот форма в процессе редактирования может менятся как угодно.
S> Прошу прощения еще не вдавался в тонкости, и выражаю больше свое видение чем знания.
S> Но у формы мняются ведь только свойства и набор подчиненных контролов (компонентов) с которыми связаны на подобие Notification.

У формы может поменятся что угодно, достаточно открыть ее код.

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

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

AVK>>>Ты не забыл о том что речь идет о форме? Вот форма в процессе редактирования может менятся как угодно.
S>> Прошу прощения еще не вдавался в тонкости, и выражаю больше свое видение чем знания.
S>> Но у формы мняются ведь только свойства и набор подчиненных контролов (компонентов) с которыми связаны на подобие Notification.

AVK>У формы может поменятся что угодно, достаточно открыть ее код.
Спасибо. На досуге поразбираюсь. А пока верю на слово.

VD>Дизайнер форм в студии создает базовый класс (обычно Form), а контролы грузит сам в режиме интерпретации.

Вот именно, что если базовый — это Form. Но, у кого как, а у меня базовый это обычно вовсе не Form.
И, соответственно, базовые конструкторы и все, что они тянут — вызывается до присвоения ISite.

AVK>Именно так . Дизайнер создает экземпляр базового класса, а не того который ты дизайнишь. Поэтому, кстати, невозможно наследовать форму от абстрактного класса.

Вот именно, что базового. Который вовсе не обязан быть Form.
Кстати, любопытно, что приватность конструктора при этом дизайнеру не мешает (слава богу).

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

iT>Вот именно, что если базовый — это Form. Но, у кого как, а у меня базовый это обычно вовсе не Form.
iT>И, соответственно, базовые конструкторы и все, что они тянут — вызывается до присвоения ISite.

В таких случаях работают и OnCreateControl и ISupportInitialise.

В общем, не выдумывай проблем на ровном месте.

VD>Чушь не говори.

Чушь? хм.. Ну ладно, я расскажу подробно, когда и почему это происходит.

Происходит это потому, что как только дизайнер видит контрол/форму, реализующую ISupportInitialize — он вставляет в код конструирования вызовы методов этого интерфейса. Что в общем, конечно, логично.

Но, если ты сделаешь потомка контрола — то при его редактировании опять в код вставляется вызов BeginInit/EndInit. И еще раз.. и еще.. пока не закончится вся иерархия.

А если это контрол, то еще один вызов будет сформирован в форме, на которой этот контрол лежит. В общем, кучу раз вызывается. А если у этой формы будет потомок — то это еще один вызов...

Вот такие дела..

P.S. Можешь не тратить время на объяснения, почему наследование контролов и форм — это плохой дизайн и кул-хацкерство


VD>Научсь отделять проблемы и решать их по отдельности. Иначе если навалить в кучу ворох даже самых маленьких проблем, ришить их не удастся, так как в голове будет каша.

Спасибо за совет

iT>>Самое прямое. Ведь мы же говорим (я, по крайней мере, стараюсь) о том, что считать нужным, а что ненужным.

VD>Ты уже второй раз демонстрируешь, что вместо того чтобы решать реальные проблемы ты пытаешся создавать проблемы и каое-как их решать. Получается раком и совершенно бессмысленно.

Я свои проблемы решаю. Проблема этих решений только в том, что они не нравятся тебе. А поскольку решения лучше ты предложить не можешь, то тут же объявляешь саму задачу "неконкретной", "ненужной", "плохим дизайном", "создавать проблемы" и проч. Ну, если тебя это успокаивает — ради бога, я не буду настаивать.

VD>Ну, хозяин барин. Я уже понял, что качество ПО тебя не трогает.

Как ты догадался?? Я действительно всегда считал, что качество — совершенно лишняя вещь. Главное — чтобы
заказчик платил как можно больше бабла!

iT>> Ну неужели не видно такой простой аналогии с историей возникновения java и generic'ов?
VD>Не. В упор не видно.
VD>И более того. Любая обратная аналогия не доказуема и их не стоит использовать для размышелий.

Конечно, не доказуема Это же не теорема, а аналогия. Для размышлений аналогии используются редко просто в силу того, что если ты о чем-то можешь размышлять, то аналогии тебе уже не нужны, а вот для объяснения — они очень подходят. Если, конечно, человек способен воспринимать аналогии. Действительно, аналогии бывают обманчивы, но обычно если человек упирается в то, что по его мнению аналогия не верна, он может указать на ключевое различие двух моделей — исходной и аналогии — которое как раз и делает аналогию неверной.

А что такое обратная аналогия?

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

iT>Происходит это потому, что как только дизайнер видит контрол/форму, реализующую ISupportInitialize — он вставляет в код конструирования вызовы методов этого интерфейса. Что в общем, конечно, логично.

iT>Но, если ты сделаешь потомка контрола — то при его редактировании опять в код вставляется вызов BeginInit/EndInit. И еще раз.. и еще.. пока не закончится вся иерархия.

ISupportInitialize актуален только для контролов и компонентов. Для формы он особого смысла не имеет. Хотя тоже будет вызван.

iT>А если это контрол, то еще один вызов будет сформирован в форме, на которой этот контрол лежит. В общем, кучу раз вызывается. А если у этой формы будет потомок — то это еще один вызов...

Ерунду говоришь. У контрола методы будут вызваны один раз.

iT>P.S. Можешь не тратить время на объяснения, почему наследование контролов и форм — это плохой дизайн и кул-хацкерство

Ты выдумываешь проблемы на ровном месте. Причем пытаешся этими выдуманными проблемами объяснить левые хаки. А чтобы подтвердить свои слова постоянно передергиваешь, неверно цитируешь и делаешь какие-то странные предположения за другий. И все это вместо того, чтобы разобраться и решить, мелкие по существу, проблемы. Вот сейчас и предыдушее предложение как раз из разряда таких передергиваний.

VD>>Научсь отделять проблемы и решать их по отдельности. Иначе если навалить в кучу ворох даже самых маленьких проблем, ришить их не удастся, так как в голове будет каша.

iT>Спасибо за совет

Пожалуйса. Не забудь им воспользоваться.

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

iT>Я свои проблемы решаю. Проблема этих решений только в том, что они не нравятся тебе.

А кому они нравятся? Так как ты не связан со мной, то мне в сущности по фигу как ты решаешь свои проблемы. Но я вжу, что ты постоянно даешь вредные советы окружающим и провоцируешь их на неверное решение. Собственно из-за этого я и отвечаю на твои постинги.

iT> А поскольку решения лучше ты предложить не можешь,

Это вранье. На все реально поставленные задачи я привел просые и эффективные решения.

iT> то тут же объявляешь саму задачу "неконкретной", "ненужной", "плохим дизайном", "создавать проблемы" и проч.

Твоя задача самоцельна. Ты не пытаешся решать те задачи которые рельно стоят перед тобой. Ты их придумываешь и решаешь уже придуманную проблему. Типа "пусть мир прогнется под нас" (с). При этом ты действительно приводишь примеры плохого дизайна и невреного решения проблем.

iT> Ну, если тебя это успокаивает — ради бога, я не буду настаивать.

Я как бы не беспокоюсь. Мне просто не хочется, чтобы в наш форум тыкали пальцем и говорили не лестные слова.

VD>>Ну, хозяин барин. Я уже понял, что качество ПО тебя не трогает.

iT>) Как ты догадался??

Ты ты своим образом мышления демонстрируешь.

iT> Я действительно всегда считал, что качество — совершенно лишняя вещь. Главное — чтобы
iT>заказчик платил как можно больше бабла!

Жаль мне твоих заказчиков.

VD>>И более того. Любая обратная аналогия не доказуема и их не стоит использовать для размышелий.

iT>Конечно, не доказуема Это же не теорема, а аналогия.

Вот и не нужно ее преводить в качестве доказательства или предпосылки.

iT> Для размышлений аналогии используются редко просто в силу того, что если ты о чем-то можешь размышлять, то аналогии тебе уже не нужны, а вот для объяснения — они очень подходят.

Только прямые. Например: "синий как небо", "датагрид имет каклоки как и листвью" и т.п. Твоя же аналогия:

VD>>Почему поздно? Очень даже вовремя. Просто ты строишь дизайн своего кода неверно. Только и всего. У МС тонна контролов и ни одих не занимается подобной еруной.

iT>Да, да, конено Если проблема не решается в текущей версии — значит, у вас проблема в дизайне. Плавали, знаем. Generic'ов уже дождались, поглядим, что будет дальше.

Является примером классической обратной аналогии. Ничего кроме демагогии на ее базе развить невозможно.

iT> Если, конечно, человек способен воспринимать аналогии. Действительно, аналогии бывают обманчивы, но обычно если человек упирается в то, что по его мнению аналогия не верна, он может указать на ключевое различие двух моделей — исходной и аналогии — которое как раз и делает аналогию неверной.

На базе аналогий вообще некорректно делать утвеждений. Ты правильно сказал. Аналогии (правда только прямые) можно использовать при объяснеии. Например, невозможно на словах обяснить что такое голубой цвет. Но легко сказать, что голубой — это цвет как у неба.

В твоем, же высказывании кроме не понятно с чего взявшейся аналогии еще и спорное утверждение прсутствует "Если проблема не решается в текущей версии". Проблема решается. Я тебе уже это демонстрировал. Других примеров, заставляющих использовать сканирование стэка, ты не привел. Но продолжаешь делать спорные утверждения и давать людям вредные советы.

iT>А что такое обратная аналогия?

Утвеpждение, что две pазличные ситуации аналогичны.

ЗЫ

Еще раз поторюсь. Если ты действительно видишь случай в ктором нельзя обойтись без трассировки стэка. То приводи его будем разбираться. Но в любом, случае совет использовать трассировку стэка как обще решение проблем инициализации неверно и вредно. Проблемы не только в скорости. Трассировка стэка может привести к проблемам с защитой, а так же не учитывать особенности дизайнеров отличных от VS.NET IDE.

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

VD>В общем, отсуствие продуманной схемы у МС не является основанием для хаков.
Основанием для любых хаков является требование к программе и необходимость её работоспособности в заданные сроки в заданных условиях. Можно сколько угодно говорить, что проверять стек "не кошерно", но если надо быстро сделать проверку на дизайн-тайм в конструкторе — это подходящий способ. Перепроектирование системы может уйти в следующую итерацию, а баги надо править в текущей...

Не будем забывать про то, что некоторые всё-таки работают по управляемому процессу, а не "как шибануло вечером под пиво"

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


O>Основанием для любых хаков является требование к программе и необходимость её работоспособности в заданные сроки в заданных условиях. Можно сколько угодно говорить, что проверять стек "не кошерно", но если надо быстро сделать проверку на дизайн-тайм в конструкторе

Таки мы услышим разумное обяснение почему проверка обязана быть в конструкторе, а не где-то еще?

O> — это подходящий способ.

Хак может быть подходящим способом только при условии, что другими средствами задача не решаема. Ни ты, ни Igor Trofimov не привели ни одного примера где такая необходимость прослеживалась бы. А посему вы занимаетесь перемалыванием воздуха.

O> Перепроектирование системы может уйти в следующую итерацию, а баги надо править в текущей...

Баги вы и закладываете. Причем не просто закладываете, а упорно советуете делать закладывать их другим.

O>Не будем забывать про то, что некоторые всё-таки работают по управляемому процессу, а не "как шибануло вечером под пиво"

Управляемостью процесса у вас и не пахнет. Вам продемонстировали как решаются проблема, а вы заниматесь бессмысленными отговорками.

ЗЫ

В обещем, причем тут веремя я понять так и не смог. Вы утверждаете, что есть какие-то непреодолимые проблемы. Привести их пример вы не в состоянии. О чем собственно тогда речь?

VD>Это вранье. На все реально поставленные задачи я привел просые и эффективные решения.

Не-а. Ты привел решения для других задач. Ей-богу, для других. См. ниже.

VD>Твоя задача самоцельна. Ты не пытаешся решать те задачи которые рельно стоят перед тобой. Ты их придумываешь и решаешь уже придуманную проблему.

Угу. Как с утра на работу прихожу, так начинаю придумывать себе задачи, да чтобы подурнее, чтобы без "кулхака", как ты это называешь, не решить Мне ж как раз за это деньги платят. А даже если и не за это — зато для души какя радость!

iT>> Я действительно всегда считал, что качество — совершенно лишняя вещь. Главное — чтобы
iT>>заказчик платил как можно больше бабла!
VD>Жаль мне твоих заказчиков.

Ты поверил, что это я всерьез или просто злишься?

VD>На базе аналогий вообще некорректно делать утвеждений. Ты правильно сказал. Аналогии (правда только прямые) можно использовать при объяснеии. Например, невозможно на словах обяснить что такое голубой цвет. Но легко сказать, что голубой — это цвет как у неба.

Доказывать утверждения нельзя, а делать на базе аналогий — можно. Утверждения можно вообще необоснованные делать.

VD>В твоем, же высказывании кроме не понятно с чего взявшейся аналогии еще и спорное утверждение прсутствует "Если проблема не решается в текущей версии". Проблема решается. Я тебе уже это демонстрировал.

Можно еще раз решение, помедленее. Я записываю...
Задача. Определить в конструкторе формы и в вызываемом из него коде (базовые конструкторы, конструкторы контролов, код свойств, OnLoad, BeginInit/EndInit и прочее, что когда-либо попадает в InitializeControl), находимся ли мы в DesignTime

VD>Еще раз поторюсь. Если ты действительно видишь случай в ктором нельзя обойтись без трассировки стэка. То приводи его будем разбираться.

Даже если я его не вижу (не могу привести краткий, самодостаточный и одновременно практический пример) — это еще не повод объявлять задачу несуществующей — тебе не кажется? В параллельной подветке мы с тобой ищем общее место для инициализации, которое вызывается разом, всегда и один раз — пока не видно такого. OnCreateControl может вызыаться поздновато — если на вкладке например, расположен. Конструктор — это железно сразу и ровно один раз.


VD>Но в любом, случае совет использовать трассировку стэка как обще решение проблем инициализации неверно и вредно.

Я не предлагал его использовать как "обще решение проблем инициализации" — это ж надо постараться так превратно понять. Я предлагал его использовать для одного и только для одного — для чего спрашивали — для теста на DesignTime. При этом я пояснил, почему и отчего стандартный способ может отвечать неправду.

VD>Проблемы не только в скорости. Трассировка стэка может привести к проблемам с защитой, а так же не учитывать особенности дизайнеров отличных от VS.NET IDE.

Вот если ты так ратуешь за невинных и глупеньких программеров, которых я тут злостно совращаю вредными советами — эти соображения тебе стоило высказать в первом своем отклике в этой ветке. И мы бы быстро и спокойно разложили бы все ограничения, плюсы и минусы всех методов по полкам. Но, конечно, проще и круче обо..ругать сразу и без подробностьей

Что касается скорости — проверять чаще всего нужно один раз на процесс, а с дизайнерами, которые не реализуют IDesignerHost, я лично не встречался. Может, есть такие. (Кстати, при текущей организации WinForms такой дизайнер вообще может быть?)

VD>ISupportInitialize актуален только для контролов и компонентов. Для формы он особого смысла не имеет. Хотя тоже будет вызван.

И не один раз. Ну так что — чушь? Или все-таки вызывается несколько раз? Значит, для начальной инициализации не очень подходит, не правда ли? Для формы он тоже кое-какой смысл имеет — он отмечает начало/окончание конструирования формы на очередном уровне наследования.

VD>Ерунду говоришь. У контрола методы будут вызваны один раз.

Ну что.. сам проверишь или сампл присылать? Или давай "в уме" разрешим. Вот почему бы ему не вставить вызов, если контрол реализует интерфейс? А почему бы не вставить вызов на следующем уровне иерархии, для потомка контрола? Вот он и вставляет. Следи: теперь кидаем контрол на форму — оба-на — опять реализует интерфейс, дизайнер вставляет вызов. А почему не вставить? Делаем контрол protected — и в потомке формы ловим еще один вызов. Ну что — веришь?

VD>Ты выдумываешь проблемы на ровном месте. Причем пытаешся этими выдуманными проблемами объяснить левые хаки. А чтобы подтвердить свои слова постоянно передергиваешь, неверно цитируешь и делаешь какие-то странные предположения за другий. И все это вместо того, чтобы разобраться и решить, мелкие по существу, проблемы. Вот сейчас и предыдушее предложение как раз из разряда таких передергиваний.

Ну давай что-ли и я поругаюсь. Ты заметил странное сообщение — и по привычке быстро отвечать быстро ответил, что все это изврат и можно проще. Позже увидел, что речь шла об особом случае и схватился за палочку-выручалочку "нафига нужно". Ну и что, что я тебе не могу сходу сказать, где и почему мне это понадобилось, но когда понадобилось, я это применил, задача была решена и теперь я этим решением особого случая делюсь. Отступить никому не хочется и поэтому ты уже вешаешь на меня избиение младенцев, выдумывание проблем, качество программ и некорректность в споре. Так рождается флейм, бессильный что-либо изменить, неинтересный (противный на определенной стадии) окружающим, бесплодный, глупый, но беспощадный Ну вот, куда мнея занесло, а ведь хотел поругаться.

P.S. Может, имеет смысл выделять потенциально флеймовые ветки — где на единицу глубины приходится очень малое число участников — и блокировать их на недельку, чтобы оба успели остыть?

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

iT>) Ты поверил, что это я всерьез или просто злишься?

Смайликов как-то рядом не видать.

iT>Доказывать утверждения нельзя, а делать на базе аналогий — можно. Утверждения можно вообще необоснованные делать.

Если утвреждение необоснованно и не явялется аксиомой, то делать то конечно можно. Но грош цена таким утверждениям.

iT>Можно еще раз решение, помедленее. Я записываю...
iT>Задача. Определить в конструкторе формы и в вызываемом из него коде (базовые конструкторы, конструкторы контролов, код свойств, OnLoad, BeginInit/EndInit и прочее, что когда-либо попадает в InitializeControl), находимся ли мы в DesignTime

Я тебе уже кажется отвечал, что конструктор формы которая меняется в дизайнере вообще не вызывается. Для предков этой формы все вызывается так как я тебе уже описывал.

Ты преврашаешь инициализацию в конструкторе из средства достижения цели в самоцель. Выбор довольно очевиден или переместить действия из конструктора в другой метод, или написать медленный, не безопасный и основанный на знании реализации дизайнера код.

VD>>Еще раз поторюсь. Если ты действительно видишь случай в ктором нельзя обойтись без трассировки стэка. То приводи его будем разбираться.

iT>Даже если я его не вижу (не могу привести краткий, самодостаточный и одновременно практический пример) — это еще не повод объявлять задачу несуществующей — тебе не кажется?

Я бы зашел с другой стороны. Зачем предлагать более медленное, более опасное, и сложное решение если есть простое и эффективное?

iT> В параллельной подветке мы с тобой ищем общее место для инициализации, которое вызывается разом, всегда и один раз — пока не видно такого. OnCreateControl может вызыаться поздновато — если на вкладке например, расположен. Конструктор — это железно сразу и ровно один раз.

Форма не может быть расположена на закладке. Если это так, то с дизайном уже задница. Для контролов прекрасно работает сапорт инициалайз.

iT>Я не предлагал его использовать как "обще решение проблем инициализации" — это ж надо постараться так превратно понять.

Как говоришь, так и понимаем.

iT> Я предлагал его использовать для одного и только для одного — для чего спрашивали — для теста на DesignTime. При этом я пояснил, почему и отчего стандартный способ может отвечать неправду.

В общем, все идет по кругу. Привести пример где без этого не обойтись ты не можешь. Но, советовать советуещ.

iT>Вот если ты так ратуешь за невинных и глупеньких программеров, которых я тут злостно совращаю вредными советами — эти соображения тебе стоило высказать в первом своем отклике в этой ветке. И мы бы быстро и спокойно разложили бы все ограничения, плюсы и минусы всех методов по полкам. Но, конечно, проще и круче обо..ругать сразу и без подробностьей

В общем, по делу тебе явно уже сказать нечего.

iT>Что касается скорости — проверять чаще всего нужно один раз на процесс, а с дизайнерами, которые не реализуют IDesignerHost, я лично не встречался. Может, есть такие. (Кстати, при текущей организации WinForms такой дизайнер вообще может быть?)

Гы. Один раз. Ты эту проверку делаешь в каждом конструкторе. И не факт, что контрол не грузится где-нить в дизайнере, но не для изменения, а именно как часть реализации этого дизайнера.

VD>Я тебе уже кажется отвечал, что конструктор формы которая меняется в дизайнере вообще не вызывается. Для предков этой формы все вызывается так как я тебе уже описывал.

Это не важно — вызываются конструкторы всех базовых форм и все, что внутри. Решение! Где решение??


iT>>Даже если я его не вижу (не могу привести краткий, самодостаточный и одновременно практический пример) — это еще не повод объявлять задачу несуществующей — тебе не кажется?

VD>Я бы зашел с другой стороны. Зачем предлагать более медленное, более опасное, и сложное решение если есть простое и эффективное?

Затем, что оно имеет более широкую область применения и я это отметил. Его опасность, сложность и скорость конкретной реализации человек может оценить и сам, лично для себя и для своего проекта. Но зато он будет знать, что ISite работает не всегда, и что в тех местах, где оно не работает — можно применить это.

Давайте никому не будем рассказывать про секрет ДВС — велосипед безопаснее, проще и дешевле. Но область его применения уже. Черт, люблю я аналогии


iT>> В параллельной подветке мы с тобой ищем общее место для инициализации, которое вызывается разом, всегда и один раз — пока не видно такого. OnCreateControl может вызыаться поздновато — если на вкладке например, расположен. Конструктор — это железно сразу и ровно один раз.

VD>Форма не может быть расположена на закладке. Если это так, то с дизайном уже задница. Для контролов прекрасно работает сапорт инициалайз.

Форма на закладке — это конечно, экзотика Но для контрола BeginInit/EndInit может вызываться несколько раз. Я уже готов по запросу прислать демо


iT>>Я не предлагал его использовать как "обще решение проблем инициализации" — это ж надо постараться так превратно понять.

VD>Как говоришь, так и понимаем.

Ай-ай.. где ж это я предлагал "обще решение проблем инициализации"? Можно цитату? Впрочем, опять я не в ту сторону рулю — решение цитата не приближает..

iT>> Я предлагал его использовать для одного и только для одного — для чего спрашивали — для теста на DesignTime. При этом я пояснил, почему и отчего стандартный способ может отвечать неправду.

VD>В общем, все идет по кругу. Привести пример где без этого не обойтись ты не можешь. Но, советовать советуещ.

Ну хоть бы и так, а что? Разве в MSDN на любой метод есть пример такого применения, где другим способом не обойтись? А советуют!

VD>В общем, по делу тебе явно уже сказать нечего.

Да дело кончилось на моей первой реплике Ни я, ни ты ничего нового к этому не добавили — так, по мелочи все, да кидание банановой кожурой


iT>>Что касается скорости — проверять чаще всего нужно один раз на процесс, а с дизайнерами, которые не реализуют IDesignerHost, я лично не встречался. Может, есть такие. (Кстати, при текущей организации WinForms такой дизайнер вообще может быть?)

VD>Гы. Один раз. Ты эту проверку делаешь в каждом конструкторе.

Кто тебе это сказал? Я — не говорил. Более того, чуть выше я говорил orangy'у что это надо посчитать один раз.
Можешь убедиться.

VD>И не факт, что контрол не грузится где-нить в дизайнере, но не для изменения, а именно как часть реализации этого дизайнера.

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

AVK>Зачем так сложно? Достаточно использовать твой контрол в кастомном UITypeEditor и все, приплыли.

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

Хотя... Если например, делать дизайнер форм для корпоративной системы — то там наверняка захочется применить и какие-то стандартные для системы контролы — причем тоже иногда в DesignTime, иногда в Runime, но из дизайнера. Ну, тут уж я вообще не знаю тогда, как выкручиваться, если надо определить DesignTime

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

iT>> Нда, тут фокус со стеком не пройдет. Хреново.

AVK>Вот тебе и причина почему хаки это очень очень плохо.

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

AVK>Выкручиваться очень просто, тут уже говорили как — выносить дизайнерский код во внешние классы, не работающие в рантайме. А если их много то лучше даже в отдельную сборку, ибо нефиг занимать память в рантайме дизайнтаймным кодом. Да и отлаживать проще.

Погодь.. изначально речь-то шла не о дизайнерах. А об обычных компонентах, которые никогда не появятся как элементы дизайнера, но им хочется что-то сделать в runtime и не делать этого в designtime. Спросить что-то у app-сервера, например. Или обратиться к какому-то большому клиентскому синглтону за чем-нибудь.

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

AVK>>Выкручиваться очень просто, тут уже говорили как — выносить дизайнерский код во внешние классы, не работающие в рантайме. А если их много то лучше даже в отдельную сборку, ибо нефиг занимать память в рантайме дизайнтаймным кодом. Да и отлаживать проще.

iT>Погодь.. изначально речь-то шла не о дизайнерах. А об обычных компонентах, которые никогда не появятся как элементы дизайнера, но им хочется что-то сделать в runtime и не делать этого в designtime. Спросить что-то у app-сервера, например. Или обратиться к какому-то большому клиентскому синглтону за чем-нибудь.

Тут orangy уже приводил пример решения подобного в случае NotifyIcon. Я о подобном.

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

AVK>>Зачем так сложно? Достаточно использовать твой контрол в кастомном UITypeEditor и все, приплыли.
iT>Нда, тут фокус со стеком не пройдет.
Ряд экспериментов показал, что фокус со стеком не проходит и в других случаях. Например, в таком:

class MyControl : UserControl 
{ 
  protected override void OnLayout(...) // в этом методе в некоторых условиях все сломается
    {
            // (1) здесь проверяем стек на предмет IDesignerHost 
    }
} 

class MyPanel : UserControl { ... на панель в дизайнере кладём MyControl, в точке (1) всё будет ништяк ... }

class MyForm : Form { ... на форму кладём MyPanel - и приплыли, в одном из вызовов OnLayout для MyControl на стеке не будет IDesignerHost ... }

O>Ряд экспериментов показал, что фокус со стеком не проходит и в других случаях. Например, в таком:

Да в общем-то в банальном OnPaint его тоже не должно быть. Но фишка в том, что в конструкторе он будет обязательно и ты это запомнишь — или для процесса или для экземпляра.

iT>Суть в том, что этот самый "хак" — работает надежно и всегда, в отличие от проверки ISite.

Хм. Пробегать StackTrace на наличие объектов, реализующих интерфейс. Нет, это не надёжно.


Во-первых, какой-нибудь левый объект может с дури реализовывать этот дизайнер-интерфейс. Никогда не знаешь, отчего вдруг тебя вызвали.

Во-вторых, unmanaged-вызовы "разрывают" StackTrace. Если между IDesignerHost и конструктором "залёг" unmanaged-вызов, ничего ты не оттрэйсишь. А MC++ может такую фишку легко подкинуть.