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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вот именно.

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

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

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

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

iT>Хотя... Если например, делать дизайнер форм для корпоративной системы — то там наверняка захочется применить и какие-то стандартные для системы контролы — причем тоже иногда в 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++ может такую фишку легко подкинуть.