А вот про метод delete - нет...
Кстати, как в KOL не стараются изничтожать дочерние контроллы, а и в нем не все таким способом изничтожается. К примеру, таймеры, потоки...
Хотя, это уже вопрос концепции, видимо
5) Про концепцию
Таки аргумент, что не все может быть "массивом" не представляется мне убедительным против именно концепции
Согласен: элементу For не следует иметь св-в динамического мультика.
Зато очень многим ведь это было бы не бессмысленно. Даже в неожиданных местах: Memory, к примеру
Эдакое разделение на "два класса" вроде не самое тупиковое место, и ничем не сложнее (вроде бы

К тому же, пока не очень ясно как именно на сегодняшнюю концепцию должен реагировать редактор форм...
Dilma, изложи свои мысли на этот предмет.
Напомню: мое предложение - гибрид концепций Delphi-1 и Delphi-2

6) Чего-то мне думается, что следует заменить элемент Run на продвинутую версию элемента Application (а может и имя ему сменить на более понятное дельфянам - типа ProcessMessages).
Добавить еще один вариант формы: Applet - и именно в него перенести св-во Caption из Application
Какой-нибудь элемент типа SysMenu будет в последствии соответствующие менюхи и менять.
И что главное - будет прозрачно понятно какие
И собственная иконка - по делу.
И именно в нем (и только в нем) делать
Applet := NewApplet(_prop_Caption);[/code]
А коль скоро такой элемент не определен до определения главной формы, творить
frm2 := NewForm(nil,'Form');
Applet := frm2;
Хотя лучше бы иметь возможность везде заменить frm2 на Applet. Пока не очень понятно как и на каком уровне это лучше делать...
[size=-2]------ Добавлено в 10:36 [/size]
[quote=Dilma]вот так на вскидку думается, что ошибок с областями видимости быть не должно[/quote]
Должно
Как только мы начнем заниматься структурированием. А абсолютным инлайнингом контейнеров.
Если абсолютный инлайлинг, то у нас всегда будет только один класс (объект) и только его методы, из которых все будет видно, безусловно.
Но предположим, что рано или поздно мы напишем такой код:
type
TSDK_0 = object
public
win_1:PControl;
win_2:PControl;
SDK_4:TSDK_3;
SDK_5:TSDK_3;
....
end;
Вопрос: как методы TSDK_3 (мы же должны предполагать что они там есть) увидят коды типа win_1.width :?: