Dilma писал(а):
ни у кого не появляется ощущения обделенности в визуальном представление скажем связи одного сплиттера с двумя соседними элементамивообще-то появлялось, но ведь их немного - можно и проглотить, а вот менеджеры наступают несравнимо активнее
Dilma писал(а):
попробуйте четко сформулировать те критерии потери визуальностипересмотрел MRA - в данном случае в списке имём менеджеров всего один! Естественно, что эту самую визуальность просто невозможно потерять, не тот случай проще говоря..
Dilma писал(а):
может ли хоть кто-то при беглом осмотре хоть примерно понять чего там происходит? Может быть у кого-то получится хотя бы блоки программы отдельные выделить?Dilma писал(а):
FormsStringTableMTAs_TabGrid.sha - вот вам классический выход из ситуации описанный по пункту 2Блин, я не специально, но правда - при беглом просмотре почти нифига не понял, минуты через 3 поймал себя, что начал ковыряться во внутренностях. Жаль что там мульты не комментированы вообще, в отличии от TreeViewEx_As_DirView..
Dilma писал(а):
Вместо итоговне надо больше защищать менеджеры, они хорошие Разговор про читаемость схемы (или визуализацию/визуальность - не уверен в правильности использования термина) продолжим после того, как появится реальная (объёмная) задача активно использующая список, хотя бы из 4-х менеджеров одного типа..
nesco писал(а):
Самое интересное то, таблицу StringTableMT удалось разложить, аж на 28 модулейnesco, не ругайся пожалуйста, я сам осознаю некоторую бредовость идеи, но - мне бы очень было интересно поюзать оба варианта одного элемента - обобщённый и распределённый (типа кликаешь в контексте элемента на строчку "расчленить" и вместо главнюка появляются много маленьких составляющих). Так глядишь годика через 2 станет ясно, что оба хороши (или один )..