Здравствуйте, Serginio1, Вы писали:
AVK>>Потому что базовый класс обычно скомпилирован и его не надо пересобирать на каждый чих при редактировании. S> Я не большой специалист в компоненто строении поэтому и спрашиваю. Реально в дизайн тайме меняются только свойства компонентов и вроде о пересборке никакой речи не идет, как и при динамическом изменении свойст в рантайме, только отрисовка и доступ к событиям в этом случае будут другими.
Ты не забыл о том что речь идет о форме? Вот форма в процессе редактирования может менятся как угодно.
Здравствуйте, AndrewVK, Вы писали:
AVK>Ты не забыл о том что речь идет о форме? Вот форма в процессе редактирования может менятся как угодно.
Прошу прощения еще не вдавался в тонкости, и выражаю больше свое видение чем знания.
Но у формы мняются ведь только свойства и набор подчиненных контролов (компонентов) с которыми связаны на подобие Notification.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, Serginio1, Вы писали:
AVK>>Ты не забыл о том что речь идет о форме? Вот форма в процессе редактирования может менятся как угодно. S> Прошу прощения еще не вдавался в тонкости, и выражаю больше свое видение чем знания. S> Но у формы мняются ведь только свойства и набор подчиненных контролов (компонентов) с которыми связаны на подобие Notification.
У формы может поменятся что угодно, достаточно открыть ее код.
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, Serginio1, Вы писали:
AVK>>>Ты не забыл о том что речь идет о форме? Вот форма в процессе редактирования может менятся как угодно. S>> Прошу прощения еще не вдавался в тонкости, и выражаю больше свое видение чем знания. S>> Но у формы мняются ведь только свойства и набор подчиненных контролов (компонентов) с которыми связаны на подобие Notification.
AVK>У формы может поменятся что угодно, достаточно открыть ее код.
Спасибо. На досуге поразбираюсь. А пока верю на слово.
... << RSDN@Home 1.1.0 stable >>
и солнце б утром не вставало, когда бы не было меня
VD>Дизайнер форм в студии создает базовый класс (обычно Form), а контролы грузит сам в режиме интерпретации.
Вот именно, что если базовый — это Form. Но, у кого как, а у меня базовый это обычно вовсе не Form.
И, соответственно, базовые конструкторы и все, что они тянут — вызывается до присвоения ISite.
AVK>Именно так . Дизайнер создает экземпляр базового класса, а не того который ты дизайнишь. Поэтому, кстати, невозможно наследовать форму от абстрактного класса.
Вот именно, что базового. Который вовсе не обязан быть Form.
Кстати, любопытно, что приватность конструктора при этом дизайнеру не мешает (слава богу).
Здравствуйте, Igor Trofimov, Вы писали:
iT>Вот именно, что если базовый — это Form. Но, у кого как, а у меня базовый это обычно вовсе не Form. iT>И, соответственно, базовые конструкторы и все, что они тянут — вызывается до присвоения ISite.
В таких случаях работают и OnCreateControl и ISupportInitialise.
В общем, не выдумывай проблем на ровном месте.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Igor Trofimov, Вы писали:
AVK>>Именно так . Дизайнер создает экземпляр базового класса, а не того который ты дизайнишь. Поэтому, кстати, невозможно наследовать форму от абстрактного класса.
iT>Вот именно, что базового. Который вовсе не обязан быть Form.
Блин, да, в VS.NET конструктор формы (если она унаследована от Form) вообще никогда не вызывается в дизайн-тайме
Внимательнее читай.
iT>Кстати, любопытно, что приватность конструктора при этом дизайнеру не мешает (слава богу).
Чушь? хм.. Ну ладно, я расскажу подробно, когда и почему это происходит.
Происходит это потому, что как только дизайнер видит контрол/форму, реализующую 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>Спасибо за совет
Пожалуйса. Не забудь им воспользоваться.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Igor Trofimov, Вы писали:
iT>Я свои проблемы решаю. Проблема этих решений только в том, что они не нравятся тебе.
А кому они нравятся? Так как ты не связан со мной, то мне в сущности по фигу как ты решаешь свои проблемы. Но я вжу, что ты постоянно даешь вредные советы окружающим и провоцируешь их на неверное решение. Собственно из-за этого я и отвечаю на твои постинги.
iT> А поскольку решения лучше ты предложить не можешь,
Это вранье. На все реально поставленные задачи я привел просые и эффективные решения.
iT> то тут же объявляешь саму задачу "неконкретной", "ненужной", "плохим дизайном", "создавать проблемы" и проч.
Твоя задача самоцельна. Ты не пытаешся решать те задачи которые рельно стоят перед тобой. Ты их придумываешь и решаешь уже придуманную проблему. Типа "пусть мир прогнется под нас" (с). При этом ты действительно приводишь примеры плохого дизайна и невреного решения проблем.
iT> Ну, если тебя это успокаивает — ради бога, я не буду настаивать.
Я как бы не беспокоюсь. Мне просто не хочется, чтобы в наш форум тыкали пальцем и говорили не лестные слова.
VD>>Ну, хозяин барин. Я уже понял, что качество ПО тебя не трогает.
iT>) Как ты догадался??
Ты ты своим образом мышления демонстрируешь.
iT> Я действительно всегда считал, что качество — совершенно лишняя вещь. Главное — чтобы iT>заказчик платил как можно больше бабла!
Жаль мне твоих заказчиков.
VD>>И более того. Любая обратная аналогия не доказуема и их не стоит использовать для размышелий.
iT>Конечно, не доказуема Это же не теорема, а аналогия.
Вот и не нужно ее преводить в качестве доказательства или предпосылки.
iT> Для размышлений аналогии используются редко просто в силу того, что если ты о чем-то можешь размышлять, то аналогии тебе уже не нужны, а вот для объяснения — они очень подходят.
Только прямые. Например: "синий как небо", "датагрид имет каклоки как и листвью" и т.п. Твоя же аналогия:
VD>>Почему поздно? Очень даже вовремя. Просто ты строишь дизайн своего кода неверно. Только и всего. У МС тонна контролов и ни одих не занимается подобной еруной.
iT>Да, да, конено Если проблема не решается в текущей версии — значит, у вас проблема в дизайне. Плавали, знаем. Generic'ов уже дождались, поглядим, что будет дальше.
Является примером классической обратной аналогии. Ничего кроме демагогии на ее базе развить невозможно.
iT> Если, конечно, человек способен воспринимать аналогии. Действительно, аналогии бывают обманчивы, но обычно если человек упирается в то, что по его мнению аналогия не верна, он может указать на ключевое различие двух моделей — исходной и аналогии — которое как раз и делает аналогию неверной.
На базе аналогий вообще некорректно делать утвеждений. Ты правильно сказал. Аналогии (правда только прямые) можно использовать при объяснеии. Например, невозможно на словах обяснить что такое голубой цвет. Но легко сказать, что голубой — это цвет как у неба.
В твоем, же высказывании кроме не понятно с чего взявшейся аналогии еще и спорное утверждение прсутствует "Если проблема не решается в текущей версии". Проблема решается. Я тебе уже это демонстрировал. Других примеров, заставляющих использовать сканирование стэка, ты не привел. Но продолжаешь делать спорные утверждения и давать людям вредные советы.
iT>А что такое обратная аналогия?
Утвеpждение, что две pазличные ситуации аналогичны.
ЗЫ
Еще раз поторюсь. Если ты действительно видишь случай в ктором нельзя обойтись без трассировки стэка. То приводи его будем разбираться. Но в любом, случае совет использовать трассировку стэка как обще решение проблем инициализации неверно и вредно. Проблемы не только в скорости. Трассировка стэка может привести к проблемам с защитой, а так же не учитывать особенности дизайнеров отличных от VS.NET IDE.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>В общем, отсуствие продуманной схемы у МС не является основанием для хаков.
Основанием для любых хаков является требование к программе и необходимость её работоспособности в заданные сроки в заданных условиях. Можно сколько угодно говорить, что проверять стек "не кошерно", но если надо быстро сделать проверку на дизайн-тайм в конструкторе — это подходящий способ. Перепроектирование системы может уйти в следующую итерацию, а баги надо править в текущей...
Не будем забывать про то, что некоторые всё-таки работают по управляемому процессу, а не "как шибануло вечером под пиво"
Здравствуйте, orangy, Вы писали:
O>Основанием для любых хаков является требование к программе и необходимость её работоспособности в заданные сроки в заданных условиях. Можно сколько угодно говорить, что проверять стек "не кошерно", но если надо быстро сделать проверку на дизайн-тайм в конструкторе — это подходящий способ.
И все таки хотелось услышать про реальную задачку в которой требуется проверка на дизайн-тайм в конструкторе.
O>Основанием для любых хаков является требование к программе и необходимость её работоспособности в заданные сроки в заданных условиях. Можно сколько угодно говорить, что проверять стек "не кошерно", но если надо быстро сделать проверку на дизайн-тайм в конструкторе
Таки мы услышим разумное обяснение почему проверка обязана быть в конструкторе, а не где-то еще?
O> — это подходящий способ.
Хак может быть подходящим способом только при условии, что другими средствами задача не решаема. Ни ты, ни Igor Trofimov не привели ни одного примера где такая необходимость прослеживалась бы. А посему вы занимаетесь перемалыванием воздуха.
O> Перепроектирование системы может уйти в следующую итерацию, а баги надо править в текущей...
Баги вы и закладываете. Причем не просто закладываете, а упорно советуете делать закладывать их другим.
O>Не будем забывать про то, что некоторые всё-таки работают по управляемому процессу, а не "как шибануло вечером под пиво"
Управляемостью процесса у вас и не пахнет. Вам продемонстировали как решаются проблема, а вы заниматесь бессмысленными отговорками.
ЗЫ
В обещем, причем тут веремя я понять так и не смог. Вы утверждаете, что есть какие-то непреодолимые проблемы. Привести их пример вы не в состоянии. О чем собственно тогда речь?
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
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 такой дизайнер вообще может быть?)
Гы. Один раз. Ты эту проверку делаешь в каждом конструкторе. И не факт, что контрол не грузится где-нить в дизайнере, но не для изменения, а именно как часть реализации этого дизайнера.
... << RSDN@Home 1.1.4 beta 1 >>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
VD>Я тебе уже кажется отвечал, что конструктор формы которая меняется в дизайнере вообще не вызывается. Для предков этой формы все вызывается так как я тебе уже описывал.
Это не важно — вызываются конструкторы всех базовых форм и все, что внутри. Решение! Где решение??
iT>>Даже если я его не вижу (не могу привести краткий, самодостаточный и одновременно практический пример) — это еще не повод объявлять задачу несуществующей — тебе не кажется?
VD>Я бы зашел с другой стороны. Зачем предлагать более медленное, более опасное, и сложное решение если есть простое и эффективное?
Затем, что оно имеет более широкую область применения и я это отметил. Его опасность, сложность и скорость конкретной реализации человек может оценить и сам, лично для себя и для своего проекта. Но зато он будет знать, что ISite работает не всегда, и что в тех местах, где оно не работает — можно применить это.
Давайте никому не будем рассказывать про секрет ДВС — велосипед безопаснее, проще и дешевле. Но область его применения уже. Черт, люблю я аналогии
iT>> В параллельной подветке мы с тобой ищем общее место для инициализации, которое вызывается разом, всегда и один раз — пока не видно такого. OnCreateControl может вызыаться поздновато — если на вкладке например, расположен. Конструктор — это железно сразу и ровно один раз.
VD>Форма не может быть расположена на закладке. Если это так, то с дизайном уже задница. Для контролов прекрасно работает сапорт инициалайз.
Форма на закладке — это конечно, экзотика Но для контрола BeginInit/EndInit может вызываться несколько раз. Я уже готов по запросу прислать демо
iT>>Я не предлагал его использовать как "обще решение проблем инициализации" — это ж надо постараться так превратно понять.
VD>Как говоришь, так и понимаем.
Ай-ай.. где ж это я предлагал "обще решение проблем инициализации"? Можно цитату? Впрочем, опять я не в ту сторону рулю — решение цитата не приближает..
iT>> Я предлагал его использовать для одного и только для одного — для чего спрашивали — для теста на DesignTime. При этом я пояснил, почему и отчего стандартный способ может отвечать неправду.
VD>В общем, все идет по кругу. Привести пример где без этого не обойтись ты не можешь. Но, советовать советуещ.
Ну хоть бы и так, а что? Разве в MSDN на любой метод есть пример такого применения, где другим способом не обойтись? А советуют!
VD>В общем, по делу тебе явно уже сказать нечего.
Да дело кончилось на моей первой реплике Ни я, ни ты ничего нового к этому не добавили — так, по мелочи все, да кидание банановой кожурой
iT>>Что касается скорости — проверять чаще всего нужно один раз на процесс, а с дизайнерами, которые не реализуют IDesignerHost, я лично не встречался. Может, есть такие. (Кстати, при текущей организации WinForms такой дизайнер вообще может быть?)
VD>Гы. Один раз. Ты эту проверку делаешь в каждом конструкторе.
Кто тебе это сказал? Я — не говорил. Более того, чуть выше я говорил orangy'у что это надо посчитать один раз.
Можешь убедиться.
VD>И не факт, что контрол не грузится где-нить в дизайнере, но не для изменения, а именно как часть реализации этого дизайнера.
Ммм.. это, конечно, возможно. Но — для очень специфических задач — когда мы пишем часть дизайнера, по сути. Может, если это будет форма, вызываемая из ToolboxItem'а? Надо попробовать будет.
Здравствуйте, VladD2, Вы писали:
O>>Основанием для любых хаков является требование к программе и необходимость её работоспособности в заданные сроки в заданных условиях. Можно сколько угодно говорить, что проверять стек "не кошерно", но если надо быстро сделать проверку на дизайн-тайм в конструкторе
VD>Таки мы услышим разумное обяснение почему проверка обязана быть в конструкторе, а не где-то еще?
Предыдущий пост был абстрактно, а не по конкретной проблеме Извини, что не уточнил. Я уже писал, что в подавляющем большинстве случаев такой хак не нужен. Однако, например, если ты посмотришь на винформовский NotifyIcon (FW 1.1), то увидишь, что там применяется другой, но хак. Там делается дизайнер, который выставляет свойство видимости после отработки конструктора, чтобы в режиме дизайна иконка не появлялась в трее. Лучше так или не лучше — судить не берусь.
O>> — это подходящий способ. VD>Хак может быть подходящим способом только при условии, что другими средствами задача не решаема.
Конечно.
VD>Ни ты, ни Igor Trofimov не привели ни одного примера где такая необходимость прослеживалась бы. А посему вы занимаетесь перемалыванием воздуха.
Не надо ярлыков. Мы рассуждаем о прекрасном — о хаках Вчера вот с удовольствием ковырял DOS-программу 92го года выпуска, на уровне ассемблера — надо было структуру базы расковырять. Получил бешенное удовольствие!
O>>Не будем забывать про то, что некоторые всё-таки работают по управляемому процессу, а не "как шибануло вечером под пиво" VD>Управляемостью процесса у вас и не пахнет. Вам продемонстировали как решаются проблема, а вы заниматесь бессмысленными отговорками.
Опять лепишь стикеры... Если ты участовал в проектах "по уму" — должен понимать, о чём идёт речь. Если нет — тогда даже чтение умных книжек не поможет...
VD>В обещем, причем тут веремя я понять так и не смог. Вы утверждаете, что есть какие-то непреодолимые проблемы. Привести их пример вы не в состоянии. О чем собственно тогда речь?
Не бывает непреодолимых проблем, бывает отсутствие времени на их решение. Ну вот срочно например надо поправить багу в продукте-выпускаемом-завтра, чтобы некий компонент стал "хорошо" вести себя в дизайнере. На перепроектирование времени нет — придётся лепить "заплатку". Или другой пример, есть уже выпущенный компонент, тут находят уже багу в поведении в ран-тайм, но связанную с поддержкой времени дизайна. Добавить ISupportInitialize — не самое лучшее решение, потому что это потребует открытия всех форм в дизайнере, фейкового изменения, чтобы код пересериализовался с учётом этого интерфейса, и перекомпиляции. Простая замена пофиксенной компоненты ничего не даст. Иначе говоря — breaking change, что не всегда приемлимо.
. Дизайнер создает экземпляр базового класса, а не того который ты дизайнишь. Поэтому, кстати, невозможно наследовать форму от абстрактного класса.
