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

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

Теперь давайте вместе подумаем над столь необдуманно брошенной фразой

и ответим на следующие вопросы:
1) что рядовому пользователю мешает не использовать новые элементы и менеджеры в старых, составляя свои схемы с использованием того, что было год или пол года назад?
2) почему высказывается только недовольство по поводу нововведений и не предлагаются иные пути решения?
Просьба подумать и дать ответы на эти вопросы.

   Теперь немного о будущем. Мы с коллегой nesco, не так давно уже проводили диспут по поводу следующего шага в использовании менеджеров. А именно в создании общей концепции построения распределенных приложений с достаточно сложной интерфейсной составляющей. Поясню о чем идет речь на примере HiAsm. HiAsm это приложение, которое совершенно очевидно состоит из следующих основных частей
- менеджер документов(визуально это панель с вкладками в верхней части)
- менеджер команд (визуально левая часть редактора команд)
- менеджер меню (правая часть редактора команд, а так же все меню и панели инструментов в программе)
- менеджер свойств (панель Свойства)
- менеджер проекта (панель Дерево проекта)
- менеджер ... и т.д. и т.п.

   Очевидно, что технически менеджер в HiAsm это не совсем тоже, что менеджер в схеме, но суть от этого не меняется. Имея такой набор менеджеров очень удобно и легко конструировать целестное приложение, не отвлекаясь на рутину связанную с управлением каждым из менеджеров и взаимодействиями между ними. Возможноли сегодня сделать такое имея в своем распоряжении исключительно достижения 157-169 версий? Невозможно. И никогда таким количеством объектов не станет возможно манипулировать, если мы не научимся разбивать схему на блоки с минимальным числом связей между ними. Так же сразу хотелось бы подчеркнуть, что все описанное выше это некая далекая цель, к которой хоть как-то хотелось бы двигаться уже сегодня.

   На самом деле я никогда не поверю, что менеджер, который на схеме есть всего лишь выбор из списка одно элемента имени другого, является чем-то непостижимо сложным и недоступным к пониманию. Сегодня есть гораздо более емкие вещи - динамические контейнеры, полиморфы, МТ, картежи - над которыми действительно можно голову поломать. Ну а вывод из всего этого такой: если кто-то не желает изучать новые технологии для построения более сложных программ(или ему это банально не нужно), то это не значит что такого же мнения придерживаются и все остальные. У нас в конструкторе каждый может делать программы в соответствие со своим уровнем знаний начиная от программ HelloWorld заканчивая приложениями с использованием скриптов и IC.