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

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

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

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

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

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

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, Вы писали:

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

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

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

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

Здравствуйте, 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>Да не при чем тут "хак", как ты это называешь. Это все к твоему "перемести в подходящее место".

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

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

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

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

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

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

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

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

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

Здравствуйте, 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>Потому что базовый класс обычно скомпилирован и его не надо пересобирать на каждый чих при редактировании.
Я не большой специалист в компоненто строении поэтому и спрашиваю. Реально в дизайн тайме меняются только свойства компонентов и вроде о пересборке никакой речи не идет, как и при динамическом изменении свойст в рантайме, только отрисовка и доступ к событиям в этом случае будут другими.