А кто кого сборет -- слон или кит ;) ?
Не надо категорично отрицать полезность и нужность фреймов. Форма это форма, фрейм это фрейм. Но навороченные формы лучше разрезать на фреймы. У нас есть в проекте (уже немаленький -- более 300 тыс.) одна форма, самая старая. Сильно навороченная, многофункциональная, сделана по технологии PageControl. Сейчас стоит задачка разрезать ее на фреймы. Преимущество -- хотя бы то, что не будем ждать -- отдай мне из VSS а то надо подправить :). Да и с фреймом проще в плане управления памятью -- не нужен, сразу удаляем, память не занимаем, как это было бы в сл-е с PageControl.
Зато другой механизм -- визардов -- с самого начала сделали на фреймах. Кррассота ! :) Общий предок -- фрейм, кот-й умеет ходить взад-вперед и описывает прочие базовые методы. Наследник уже их реализовывает. Вставляется (с помощью виртуальных конструкторов) все это тоже в фрейм, кот-й является владельцем визарда и умеет им управлять. Получилось красиво, удобно. И главное -- независимость кода. Можно каждый визард спокойно править, не трогая соседов, кот-е появляются в том же месте. И встроить куда угодно можно. Например один из визардов поставили в одном приложении. Когда позже понадобилось его добавить в основное -- проблем не было,легко и аккуратно.
Одно из приложений у нас так и сделано -- GXOutlookBar выбирает нужный визард и вперед. Все на фреймах ;).
Вопчем каждому овощу свое место. А главное что бы голова была на месте и об ООМ и ООП не забывать ;) !

tygra, совсем не зачем так орать :).
У меня нет столько здоровья что бы морочится с ManualDock -- есть задачки поважней, чем 10 000 раз писать "мама мыла раму".
И не в докинге дело... Дело в и идеологии и ООП. С фреймами проще произвести декомпозицию, не задействуются лишние ресурсы. И т.д. и т.п. Вопчем за доолгое время разработки пожалеть, что не сделал это фреймом приходилось. Наоборот - еще нет :).

Байт говоришь... Ну сравни 2 калсса -- TForm и TFrame...

Мама мыла раму -- это каждый раз Dock и пр.
Что касается сравнения классов... При использовании того же вставляния формы в форму мы имеем 2 экземпляра класса TForm. С фреймами -- 1 форму и один фрейм. Я уже не говорю про то что при докинге дельфя делает всем контролам Recreate. Тоже не фонут изюму...
Ребята, да делайте как хотите. Главное с головой :). И без экстремизма ;).

Да tygra ведь пишет, что нафиг не нужны фреймы потому как функциональность фреймов как контейнеров контролов можно повторитьиспользуя ManualDock. Вооот :). Мне такое решение не нравится, но это уж мое личное дело :). И вот тут я и говорю, что докинг докингом, но он ведь жрет -- и лишний экземпляр довольно немаленького класса создается и контролы рекреатятся (мы с этим воевали помнится. Ой....)

To kylix_dev
Не надо мучаться с visibile. Я просто уношу и создаю нужный фрейм. Вот так

procedure TWizardFrame.SetWorkFrame(Value: TClassWorkFrame);
begin
// Освобождаю старый экземпляр
SafeFreeObj(FWorkFrame); // Это наша хитрая убивалка объектов.
FWorkFrame := Value.Create(Self); // вот эти 2 строчки собственно и суть
FWorkFrame.Parent := Workpage;
FWorkFrame.Align := alClient; // Align естественно выставляешь как хочешь.
// Ля-ля тополя по иницалилизации прочих потрохов.
.........
end;

Преимущество -- экономится память -- лишние фреймы в ней не сидят. В эту процедуру передается class reference -- вставляется любой мой фрейм с вирртуальным коснтруктором. В твоем же случае ты просто повторяешь функциональность TPageControl.
Фреймы BTW создаются с помощью визуального наследования (это для pranclin :) ).

To tygra
Use the source Luk ! ((c) Borland ) :). Просто возьми и сравни исходники 2-х классов TForm и TFrame.
По поводу recreate. Нам он сильно мешал. Контролы переинициализируются. А когда был TListView не виртуализированный то этот чертов док вообще втыкал.