Еще раз перечитав эту статью, а именно пару абзацев про грамотное поведение окон, возникла идея применить это на практике. Как раз есть форма, до отказа набитая всякими элементами управления (далее - контролами), в числе которых имеются и такие, из которых могут выпадать вспомогательные окошки. А именно: ComboBox (в режиме DropDownList) и DateTimePicker. Из первого выпадает список возможных вариантов, из второго - более-менее симпатичный календарик.

Идея проста как две копейки - как только фокус попадает в какой-нить из этих контролов, он (контрол) тут же разворачивается во всей своей красе. Это спасает пользователя от лишнего судорожного хватания мыши и тыканья ею же в вышеупомянутый контрол.

Сразу скажу, что с ComboBox'ом особых проблем не возникло. Правда вызвало некоторое удивление то, что сворачивание/разворачивание списка осуществляется не методом, а свойством, что несколько противоречит здравому смыслу. Все таки сворачивание/разворачивание - это действие, а не характеристика.

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

Ладно, нашел я комбо-боксовое свойство DroppedDown и быстренько соорудил метод:

private void Combo_Enter(object sender, EventArgs e)
{
	ComboBox cb = (ComboBox)sender;
	cb.DroppedDown = true;
}

и подцепил на него события OnEnter от всех комбо-боксов.

Естественно все скомпилировалось, запустилось и даже заработало. :) Возник соблазн подцепить до кучи еще и дате-тайм-пикеры. Снова полез в MSDN, посмотреть, как же будет зваться свойство, разворачивающее календарь, ибо, наученный горьким опытом копания в коде майкрософта, я твердо знаю, что метод, выполняющий одни и те же действия в разных (пусть даже схожих) контролах будет зваться по-разному. И, как показывает практика, может оказаться вовсе и не методом, а например свойством или даже событием... :)

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

• Метод DrawToBitmap, позволяющий (наверное) нарисовать наш элемент управления в заранее созданный битмап. Интересно, нарисует только строчку с датой или еще и развернутый календарь??? Кому и зачем это может понадобиться - для меня загадка.

• GetAutoSizeMode возвращает одно из значений перечисления AutoSizeMode, которое содержит всего два таких значения: GrowAndShrink и GrowOnly.

  Нафига это надо, если у контрола есть свойство AutoSize. Поменяйте его тип с bool на int и к списку свойств GrowAndShrink и GrowOnly добавьте еще и None, и можно "облегчить" класс на целый метод.

  Чуть ниже нашел то, о чем уже писал в предыдущих постах: This property supports the .NET Framework infrastructure and is not intended to be used directly from your code. О как! Оказывается свойство есть, но пользоваться им низзя! Спрашивается, зачем оно тогда есть? Аа-а-а, да! Это будет наверное реализовано в будущих версиях... Или уже было реализовано в прошлых... Все равно маразм! :(

• Свойства CompanyName, ProductName и ProductVersion существуют вообще везде, где только можно. Понятно, нужно знать кто и когда соорудил тот или иной класс, особенно если это коммерческая разработка. Но вот только не ясно, какое именно отношение эти свойства имеют к календарю, ровно как и к любому другому контролу.

• Controls - коллекция внедренных контролов. Никогда бы не подумал, что человеку в здравом уме придет в голову использовать строчку ввода даты как площадку для размещения дополнительных элементов управления. Видимо я старею, не поспеваю за прогрессом, отстаю от жизни, а все нормальные кодеры уже давно пихают туда таблицы, прогресс-бары и кнопки всех мастей. :)

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

• Идем дальше. Свойство HasChildren возвращает логическое значение, точно определяющее, есть ли у нас дочерние контролы али нет таких. Видимо, по мнению майкрософта, пользователи их библиотек настолько тупы, что для них нужно было создать отдельное свойство, а просто сравнить с нулем количество элементов в массиве Controls они не догадаются. Жуть. :(

• DropDownAlign - тоже очень полезная вещь. Вот только реальной практической пользы в нем я тоже не нахожу.

• Отдельно стоит рассмотреть целую коллекцию свойств, которой обладают абсолютно все контролы. Это Height, Width и Size, а также их сородичи: Left, Top и Location. Причиной их появления стала все та же предусмотрительность дядек из Microsoft, которые (для нашего "удобства") тупо продублировали одни и те же свойства, обозвав их разными именами.

  Сюда же стоит отнести и свойства Right и Bottom. Наверное рядовой программер не в состоянии запрограммировать операцию сложения двух целых чисел и ему для определения координат окна нужно ввести дополнительные свойства.

• Region - а вдруг кому-нить захочется сделать календарик круглым или с дыркой. Нельзя отнимать у программиста-разработчика такую бесценную возможность!

• MaximumSize и MinimumSize. Эти два свойства предназначены видимо для тех мега-программеров, которые осилили учебник языка C# только до раздела "События", а дальше - забили. Т.к. если разработчик знает, что такое события и как отследить изменение размеров окна, то для него потребность в этих свойствах никогда не возникнет.

• Text и Value. Тоже братья-близнецы. Созданы специально для ленивых, которым влом написать a = dtp.Value.ToString(). Теперь у них есть более короткий (и естественно более понятный) вариант: a = dtp.Text.

• FindForm и Parent. Еще один способ облегчить тяжелую жизнь программистам: циклы типа while(m.parent != null) m = m.parent; нынче не в моде. Нам надо отдельное свойство для решения таких сверх-сложных задач.

• Ну и под конец два гениальных события: ContextMenuChanged и CursorChanged. Первое наступает, когда у контрола изменилось контекстное меню (гениально, правда???), второе - (держитесь за стул, ибо упадете) наступает, когда поменялся курсор.

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

Вот такой вот цирк.

Но суть этой статьи сводится не к тому, что в библиотеке .NET Framework масса лишнего мусора, а к тому, что ни свойства, ни метода для программного разворачивания календаря я так и не обнаружил. Наверное про него гении из майкрософта просто забыли. Еще бы! Ведь надо было запрограммировать весь вышеописанный бред, а сроки сдачи коммерческого проекта .NET Framework 2.0 ведь не резиновые, вот и не успели...

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

Зато получил массу примеров, как не нужно проектировать движки. Постараюсь учесть накопленный опыт в своей CMS. :)

Microsoft открыла исходные коды .Net Framework (исходники)

Microsoft заявила, что позволит сторонним разработчикам проверять исходный код для библиотек .Net Framework, чтобы помочь создавать лучшие приложения. Правда, для этого разработчикам сначала придется запастись платформой Visual Studio 2008. Проект получил название .Net Reference Source, в него входят .Net Base Class Libraries, включая System, System.CodeDom и System.ComponentModel; ASP.Net, включая System.Web.Extensions; Windows Forms; и Windows Presentation Foundation. Также предлагаются ADO.Net и XML. Впервые о проекте Microsoft заговорила в октябре прошлого года, в течение последующих недель и месяцев компания добавит библиотеки LINQ (Language Integrated Query) и Windows Communication Foundation.

Запуск .Net Reference Source планировался на прошлый месяц, но Microsoft решила несколько продлить обратную связь и обсуждение с разработчиками. По словам Microsoft, запущенный проект "обеспечивает намного лучшее понимание того, как работают библиотеки .Net Framework и позволяет создавать лучшие приложения, совершенствуя их использование". Подробности, описания и инструкции по работе с предоставленными исходными кодами можно найти в блоге Шоуна Барки (Shawn Burke), руководителя отдела развития Microsoft.