даже предложение конкретное сделал уже про цвета, надо только подумать как это сделать поудобнее - чтобы не портить иконку элемента.. может букву менеджера внизу справа (как у ярлыка)



цвет буквы Н соответствует цвету менеджера хинта, а L - соответственно слоя. Можно с размером шрифта поиграться, ну или как-то по другому может кто предложит.
------------ Дoбавленo:

пусть вас не смущает рельеф кнопки - на этой машине такая цветовая схема выставлена..

Рискну с другой стороны подойти к проблеме.

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

   Почему потеря визуальной связи в данном случае никого не смущает? А потому, что нам в процессе проектирования логики нашей программы эта связь абсолютно ни к чему. Тоже самое и с менеджерами - как только мы начинаем их изучать, то нам непременно кажется будто это сложно только потому, что появляется новый тип связи, явно не представленный на схеме и, что самое главное, как и в случае со сплиттером не несущий никакой смысловой нагрузки. В моем понимании "визуализировать" это значит дать возможность наглядно представить процессы, происходящие в схеме. Что наглядно отображает связь скажем интерфейсного элемента с менеджером слоев? Да ничего она не отображает кроме самого факта наличия такой связи. Это тоже самое как протаскивание в электроники проводов питания к каждой микрухе на схеме - ну да действительно без такой визуализации очень сложно понять запитывается микросхема на плате или она там для красоты впаяна...

   Поехали дальше. Откройте один из примеров, насыщенных менеджерами - MRA.sha, WikiCenter.sha и попробуйте четко сформулировать те критерии потери визуальности, которые по вашему там имеются. Только после этого читайте дальше:

1) Оба примера используют TreeViewTrain и MRA_Base в единственном количестве. А это значит, что говорить о потере визуальности между скажем TreeViewTrain и TVT_ChangeNode или между MRA_Base и MRA_Groups совершенно бессмысленно.
2) Откроем пример FormsTreeViewEx_As_DirView.sha - вот вам классическое построение схемы без использования менеджеров, что называется "все в одном". Внимание вопрос: может ли хоть кто-то при беглом осмотре хоть примерно понять чего там происходит? Может быть у кого-то получится хотя бы блоки программы отдельные выделить? Или кто-то скажет, что свои схемы с тем же центральным элементом он делает иначе? Ок, тогда переходим к пункту 3
3) Откроем пример FormsStringTableMTAs_TabGrid.sha - вот вам классический выход из ситуации описанный по пункту 2. Никому ничего не напоминает? Центральный элемент обвешан бреками и вся программа разбита на аккуратные ровные блоки... А по наблюдениям половина новичков большие программы именно так и строит. Т.е. бреки с невнятными названиями для некоторых предпочтительнее стандартных элементов с информативными иконками и что самое главное их использование почему-то не нарушает представлений о визуализации и является более понятным, чем абсолютно такое же связывание через менеджер...

   Вместо итогов: почуствовать преимущества использования данного подхода можно только всецело используя его в своих программах. Так если бы HiAsm был 3D конструктором, то по оси Z мы бы увидели как минимум три слоя - визуальное представление элементов на форме, схему и последний слой менеджеры. Сегодня имея 2D редактор мы не видим связей первого слоя со вторым вообще(кстате замечу, что это никого почему-то не смущает), а второго с третьим видим только через Alt и то не полностью. И именно такая структура присутствует в голове при проектирование схем. Были у нас попытки спресовать первые два слоя - ничего хорошего из этого не вышло, теперь вот есть желание и вторые два слить вместе...

Практически то же самое я недавно выложил на нескольких элементах будущей серии MTStrTbl, которая полностью разбита на микроэлементы и построена по технологии менеджеров, где роль сервера выполняет сам контрол таблицы, а все остальное пристегивается как клиенты (за исключением некотрых специфических модулей, таких, как менеджер пользовательской отрисовки или менеджер событий, последний, кстати, может каскадироваться в пределах одного уровня, заменяя Hub с кучей линков)

Самое интересное то, таблицу StringTableMT удалось разложить, аж на 28 модулей, это не учитывая того, что один модуль я не стал дискретизировать из-за редкости его использования

вообще-то появлялось, но ведь их немного - можно и проглотить, а вот менеджеры наступают несравнимо активнее


пересмотрел MRA - в данном случае в списке имём менеджеров всего один! Естественно, что эту самую визуальность просто невозможно потерять, не тот случай проще говоря..

это говорит только о том, что автор не стремился эти самые блоки выделить (или у него так получилось). Не могу похвастаться обратным, но стремлюсь


Блин, я не специально, но правда - при беглом просмотре почти нифига не понял, минуты через 3 поймал себя, что начал ковыряться во внутренностях. Жаль что там мульты не комментированы вообще, в отличии от TreeViewEx_As_DirView..


не надо больше защищать менеджеры, они хорошие Разговор про читаемость схемы (или визуализацию/визуальность - не уверен в правильности использования термина) продолжим после того, как появится реальная (объёмная) задача активно использующая список, хотя бы из 4-х менеджеров одного типа..


nesco, не ругайся пожалуйста, я сам осознаю некоторую бредовость идеи, но - мне бы очень было интересно поюзать оба варианта одного элемента - обобщённый и распределённый (типа кликаешь в контексте элемента на строчку "расчленить" и вместо главнюка появляются много маленьких составляющих). Так глядишь годика через 2 станет ясно, что оба хороши (или один )..

Напишу просто.
Почему то всё больше хочется вернутся к версии где нибудь 157-169.
и спокойно делать свои маленькие программки без всяких заморочек.

Вячеслав, не стой на пути у прогресса а если встал - отойди

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

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

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

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

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

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

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

Потому, что раньше Hiasm создавался для пользователей.

"кто уже успел вплотную занятся менеджерами и без проблем их использует в своих программах "
(Каюсь. Чистой воды плагиат - взял из поста выше - мои только выделение и знак вопроса в конце. )

Очень хотелось бы узнать.

Я, с момента их создания, или я уже не в счет
В первую очередь, я такой же пользователь, как и все вы. И не я создал идею менеджеров, я просто ее понял, и никто не мешает понять ее вам.
------------ Дoбавленo:


И где наблюдаются проблемы, в чем конкретно

И



О чем тогда вообще разговор

ты не в счет.
Я тоже пользуюсь. Хотя сказать, что без проблем - не могу.

Взять самый первый - HintManager.
1. Есть свойство Font, в диалоге которого есть выбор цвета шрифта.
2. И есть в свойствах компонента: HintTextColor=Цвет текста всплывающей подсказки

Выбрал цвет в окне диалога, а надпись черная. Только потом увидел где выбирать цвет надписи.

А чего молчал

Добалено перекрытие Font.Colorом свойства HintTextColor при ненулевом (отличном от clBlack) цвете

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

А зачем оставил свойство HintTextColor . Только не аргументируй совместимостью . Кроме примеров не видел в выложенных схемах применения HintManager, а вот заставить начинающего применять метод тыка - запросто.

Если начинающий залез в Font.Color, то он не совсем уже начинающий. А может кто не захочет использовать Font.Color, но не нужно ему будет менять шрифт, а так придется лезть в шрифт и менять ему цвет, пусть уж лучше останется.


Это не баг, и критически ни на что не влияет, только создает дополнительные вопросы.

nesco, извини, но видно я вчера поздно лег - нифига не понял.
Слушай, а может еще и в настройки HiAsma добавим выбор - Цвет текста всплывающей подсказки.
- тогда у всех компонентов , имеющих свойство Font - срочно добавить отдельное свойство FontColor.
Это не я - это ты до этого дорассуждался.