Ответ был найден на MSDN форуме, но применительно к MFC. Но в Delphi эта проблема также встречается и решается аналогично. Вот исходный код, который поможет исправить проблему. Его нужно добавить к дочернему окну (FormStyle = fsMDIChild).

type
  TMDIChild = class(TForm)
  private
    procedure WMGetMinMaxInfo(var Message: TWMGetMinMaxInfo); message WM_GETMINMAXINFO;
  ...
  end;
...
(*
Оригинальный комментарий к решению:
--------------------------------------------------------------------------------
Заплатка на MFC версий ниже 8.0
 
В MFC версиях 8.0 на Vista есть проблема, когда
окно дочернего MDI фрейма максимизируется при максимизированном
родительском MDI фрейме. В этом случаи максимальный размер окна ограничивается
данными структуры MINMAXINFO, которые были вычесленны ранее
системой при заданных стилях окна.
 
Однако сам MFC в процессе ресайза этого окна любит менять ему
стили на ходу в результате система путается и MINMAXINFO содержит неправильные
данные.
 
Это было не критично на XP и более старых системах, т.к. ошибка
была в 1 пиксель, теперь же на Vista, когда бордюр имеет занчительную ширину (4
пикселя), эта ошибка стала заметна (как раз на эту ширину - 4 пикселя).
 
Чтобы исправить ошибу я вручную правлю структуру MINMAXINFO под
максимально возможный размер окна.
--------------------------------------------------------------------------------
 
Smike: Похоже этот баг перенесли и в Delphi :)
*)
 
procedure TMDIChild.WMGetMinMaxInfo(var Message: TWMGetMinMaxInfo);
begin
  if WindowState <> wsMaximized then
    inherited
  else
    with Message.MinMaxInfo^ do
    begin
      if ptMaxTrackSize.X < ptMaxSize.X then ptMaxTrackSize.X := ptMaxSize.X;
      if ptMaxTrackSize.Y < ptMaxSize.Y then ptMaxTrackSize.Y := ptMaxSize.Y;
    end;
{ // Если не жалко пару десятков килобайт
  // в исполняемом файле - можно использовать функции модуля Math
  if WindowState <> wsMaximized then
    inherited
  else
    with Message.MinMaxInfo^ do
    begin
      ptMaxTrackSize.X := Max(ptMaxTrackSize.X, ptMaxSize.X);
      ptMaxTrackSize.Y := Max(ptMaxTrackSize.Y, ptMaxSize.Y);
    end;}
end;

В первую очередь, я нашел в нем ту функциональность, которая как раз была мне нужна. В приложении необходимо создавать и выбирать файлы в определенной папке и её подпапках. В TOpenDialog нельзя запретить смену каталога. В TFileOpenDialog — можно! Появилось событие OnFolderChanging, где вот таким вот простым кодом мы можем запретить, например, переходить в папки нижнего уровня по сравнению с начальной:

procedure TForm1.FolderChangingEvent(Sender: TObject;
  var CanChange: Boolean);
begin
  CanChange := AnsiStartsText(FileOpenDialog1.DefaultFolder,
                              FileOpenDialog1.FileName);
end;

Это как раз реализует нужную мне функциональность. Это одна из тех «мелочей», которыми наполнена Windows Vista, но которые так приятно облегчают работу и программистов, и пользователей.

Какие же еще возможности приподносит нам TFileOpenDialog? Это события OnFileOkClick, которое позволяет запретить закрывать диалог в случае неудовлетворительного выбора, и OnShareViolation, позволяющее задавать реакцию на выбор файлов, используемых другими приложениями.

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

TFileDialogOption = (
 fdoOverWritePrompt,
 fdoStrictFileTypes,
 fdoNoChangeDir,
 fdoPickFolders,
 fdoForceFileSystem,
 fdoAllNonStorageItems,
 fdoNoValidate,
 fdoAllowMultiSelect,
 fdoPathMustExist,
 fdoFileMustExist,
 fdoCreatePrompt,
 fdoShareAware,
 fdoNoReadOnlyReturn,
 fdoNoTestFileCreate,
 fdoHideMRUPlaces,
 fdoHidePinnedPlaces,
 fdoNoDereferenceLinks,
 fdoDontAddToRecent,
 fdoForceShowHidden,
 fdoDefaultNoMiniMode,
 fdoForcePreviewPaneOn
);

Остановимся на значениях, не имеющих аналогов. Часть из них настраивает вид самого диалога:

• fdoForcePreviewPaneOn отображает панель предварительного просмотра;
• fdoDefaultNoMiniMode запрещает открытие диалога в сжатом виде (только строка ввода имени файла) — только для диалогов сохранения;
• fdoHidePinnedPlaces убирает стандартные избранные ссылки, собственные мы по прежнему можем задавать (!);
• fdoHideMRUPlaces описывается как «Hide places of recently opened or saved items», но реально мне не удалось пока понять, о чем идет речь.

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

А вот свойство fdoNoChangeDir хоть и есть среди возможных значений, но как уверяет справочная система, это значение не используется. Это и не удивительно, ведь есть более гибкое событие OnFolderChanging.

В новом диалоге есть и другие полезные свойства и методы. С помощью коллекции FavoriteLinks можно добавлять собственные избранные ссылки. Свойства FileNameLabel, OKButtonLabel, Title позволяют изменить названия отдельных элементов интерфейса диалога (текст перед полем ввода файла, текст кнопки OK и заголовок диалога). Старый TOpenDialog позволял изменять только собственный заголовок. Коллекция FileTypes более наглядно, чем свойство Filter из TOpenDialog позволяет задавать фильтры для диалога. Особенно удобно, что это индексированный список, таким образом легко можно проверить, какому расширению соответствует тот или иной тип, используя свойство FileTypeIndex.

Скачать модифицированный вариант можно здесь:
http://mikesoft.ws/components/mousepan/

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

А вот буквально только что провел интересное наблюдение. Если в меню есть ярлык на *.url-файл и он находится в зоне видимости, то Windows Explorer начинает сильно потреблять ресурсы процессора. Причина этого также неведома. Хотя, как по мне, то делать такие ярлыки — дурной тон, лучше размещать сами *.url-файлы в меню.

Издревле эту проблему решали с помощью make-файлов, которые были придуманы в Bell Labs, вероятно для сборки первых юниксов. Вместе с Delphi поставлялась и поставляется консольная утилита make.exe, которая и занимается сборкой проекта используя makefile. Но данный подход имеет существенный недостаток: makefile нужно писать вручную, в Delphi нет инструментов для его написания. А это значит, что придется задавать вручную пути ко всем компонентам, описывать параметры компиляции, директории для вывода промежуточных (DCU, OBJ) и конечных файлов (EXE, DLL) файлов.

К сожалению, такой подход долгое время был единственным возможным способом автоматической компиляции проектов. Несмотря на то, что все параметры, использующиеся средой Delphi для компиляции, всегда сохранялись вместе с проектом. До Delphi 7 включительно это были *.cfg и *.dof-файлы. В первом сохранялись параметры компиляции, а во втором все опции диалога Project Options. Потом появились файлы *.bdsproj, где хранилась вся информация о проекте. Но это не дало никаких преимуществ: компилятор DCC32 не понимает этих файлов и соответственно автоматическая компиляция невозможна.

Серьезный сдвиг произошел в Delphi 2007, где используется MSBuild Engine для компиляции проектов. Как оказалось, это дает именно то что нужно.

В Delphi 2007 на смену файлам *.bdsproj пришли файлы *.dproj (Delphi-проекты, для C++ Builder 2007 они имеют расширение *.cbproj). Эти файлы не просто содержат параметры проекта, они заодно и являются файлами инструкций сборки для MSBuild. «Скормив» такой файл MSBuild мы сможем скомпилировать проект так же, как если бы мы компилировали его в среде Delphi: с учетом всех путей, конфигураций, опций компилятора и используемых директорий.

С помощью MSBuild процесс автоматической сборки проекта становится до элементарного простым. Составляем файл Build.cmd примерно такого содержимого:

call rsvars.bat

msbuild MyProject.dproj /p:configuration=Release

Первая строчка вызывает файл rsvars.bat. Он находится в $(BDS)Bin и содержит переменные среды для MSBuild. Затем вызывается сам MSBuild, причем указывается конфигурация Release.

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

Замечание: в Delphi 2009 конфигурация передается параметром config вместо configuration. Таким образом комманда компиляции будет выглядеть:

call rsvars.bat

msbuild MyProject.dproj /p:config=Release