vikttur,  Благодарю, что просмотрели видео. Я собственно пол дня убил на то, чтобы его создать.
1. По управлению. Что значит отбираю клавиатуру? Я ж именно на клавиатуре жму стрелки. Более того, был сознательный уход от пользования мышью. Я сторонник горяцих клавиш, потому что работа с ними машинальна, вне зависимости от текущего положения курсора не нужно думать, куда его подводить и терять время на выбор пункта меню. Рука на стрелках и машинально набирает одно из четырех нажатий. Все это происходит мгновенно и не задумываясь. Да, порой путаюсь от того, что сам постоянно переделываю набор команд и не успев привыкнуть вношу новшества. Согласитесь, с новым интерфейсом всегда нужно время на адаптацию к нему
Я с вами соглашусь, управление через события не идеально и есть вопросы. Но с точки зрения скорости работы как раз оно дает возможность работать машинально и не мечась по всем клавишам, держа руку в одном месте. Это скорость и даже простота. Но, да, нужна привычка. Все так же, как и на работу с горячими клавишами.
В принципе ни что не мешает продублировать систему управления традиционными интерфейсами. Но у меня тупо не было времени заниматься вопросами доработки. Логпрог - концепт. Скелет, на котором постоянно опробуются идеи и параллельно идет использование продукта для собственных нужд.
2. По скринобдэйтинг. Это пример все той же постоянной модернизации. Одним из последних изменений была как раз возня со скринобдэйтинг. В коде, отрисовывающем таблицу, как минимум десяток раз применена эта функция. Проблема в том, что промежуточные обновления при отрисовке требуются хотя бы для того, чтобы показывать изменения в статусбаре. Меня задолбала собственная недоработка, при которой в результате каким-то образом при несвоевременном использовании скринобдэйтинг статусбар при отрисовке таблицы периодически начинал показывать свое прошлое значение. Причем это было очень странное повдение экселя. Само свойство статусбара было уже новым и когда мне нужно было его обновить, то в коде фигурировало screenupdating=true. Но при исполнении кода почему то периодически возвращалось старое содержимое экрана со старым статусбаром. Я много лет не заморачивался, но на днях меня это достало. Я поотключал не думая практически все screenupdating=false на начальном этапе отрисовки таблицы и избавился от одной проблемы, вернув старую детскую - шапка таблицы рисуется дрыгаясь. Как видите, вопросов для доработки очень много. У меня банально нет времени вылизывать до идеала все мелочи, т.к. до окончательного варианта сам же еще 10 раз все промежуточное попеременяю. Прошу не придавать значения не принципиальным недоработкам. Продукт абсолютно сырой в силу того, что он не тривиален, а делать все приодится в одни руки урывками в свободное время. Для меня вот важнее решить вопрос с распределением базы данных из одного файла на несколько, чем подправить дрыгание, убив час на то, чтобы наконец расставить в коде подпрограммы отрисовки screenupdating как положено или же оформить красивое меню в выпадающими списками. Не удивляйтесь. Решаю концептуальные вопросы. До деталей руки просто не доходят.
4. По скорости загрузки. Нет, тут дело не в условном форматировании и не в именах. Всего этого не используется. Формат в столбце определен тем, который я задаю в описателе типов. Там есть свойство для каждой колонки - формат. Этот формат тупо копируется на все строки колонки, с которой он сопоставлен. Так что в коде одна единственная строка с copy. и на этом код больше ничего не форматирует в таблице. Условным форматом пользуюсь охотно в более простых своих приложениях. Люблю этот инструмент. Но в Логпрог место ему не вижу. Здесь его нет. Почему грузится медленно?
70% времени прорисовки отнимает формирование массива данных для отрисовки. По сути это запрос на выборку из базы данных. Как она происходит: лопатятся все строки листов хранения данных определенного типа. У каждой из них есть ссылка, указывающая на перечень разделов, в которые данная строка включена. Проверяется каждая такая ссылка каждой строки данных типа на то, попадает ли данная запись в раздел, который следует отрисовать. Кроме того, если не попадает, попадает ли она в какой-нибудь подраздел из раздела, в который нужно отрисовывать. Если попадает, то ее помечают на отрисовку в конце отрисовываемого списка. Такая выборка- это уже не тривиальный вложенный цикл обработки для каждой строки данных в типе. А данных может быть несколько сотен тысяч! Более того, данные эти не умещаются порой на одном рабочем листе и хранятся на нескольких. Выборка задействует еще и вспомогательные циклы перебора мест хранения данных типа. (собственно вопрос, обсуждаемый в теме)
20% времени занимает отрисовка ссылочных граф. У меня реализована возможность отрисовывать не сами ссылки на какие-то таблицы, а части данных этих таблиц (до четырех граф) получаемые по ссылке. Т.е в памяти базы данных у меня хранится ссылка на другую таблицу. А при отрисовке уже рисуются сами данные, выдернутые по этой ссылке. Например, у меня есть таблица с информацией о заявках на товар разным поставщикам. В этой таблице есть графа со ссылкой на поставщка. Поставщики и информация по ним уже в другой таблице. Вот какой-то из поставщиков был у нас ООО "Рога и Копыта", а потом передумал и бегая от налогов стал ООО "Копыта и рога". В таблице поставщиков я сделал соответствующее исправление его названия. А когда я захочу отрисовать таблицу заявок, то в ней уже не будет устаревшей информации ООО "Рога и Копыта". Там же, в базе данных указана лишь ссылка, а не сама информация. При отрисовке ссылка трансформируется в конкретную информацию по ссылке. Причем, выгружаемую сразу в несколько граф. Я могу в таблице с заявками заполнить сразу 4 графы информацией по единственной ссылке на таблицу с поставщиками. Это название поставщика. Это контактный телефон, адрес эл почты, Фио ответственного лица. Его должность. Вся эта информация 4х граф не хранится на листе хранения данных по отрисовываемому типу - заявок.  Хранится только ссылка на элемент таблицы поставщиков. А вот в тип заявок по ссылке будет отрисовано аж 4 графы! Т.е. отрисовка не тривиальна. Она модийицирует и трансформирует кросссылочную информацию, разворачивая ее. А теперь представьте, что в показанной на видео таблице в одной только записи\строке данных используется как минимум полтора десятка различного рода ссылок. Причем часть из них еще и множественные - т.е одна строка данных ссылается на несколько строк другой таблицы (например номера телефонов так могут выбираться из таблицы телефонов). Я молчу про то, что иногда используется механизм многократного вложенного выбора информации по ссылке. Т.е при отображении одной записи одного типа прорабатывается информация многих записей во многих других типах помимо отрисовываемого. Громадный вычислительный объем.
10% Ну и наконец сама процедура отрисовки очень не тривиальна. Для ускорения ее работы в ней использованы такие ухищрения, как анализ последовательно расположенных блоков данных информации и копирование\перенесение из базы данных на лист контекста их одним блоком с помощью отдельной процедуры перенесения range диапазонов по address.

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

По правде сказать, я редко им пользуюсь. Работаю в основном машинально. Т.к базовые операции в 90% случаев одни и те же во всех таблицах. А специфические операции в основном висят на макросах. Мне некогда тщательно все прорисовывать и особенно в наиболее свежих еще не доработанных таблицах эти макросы я тупо вызываю по alt-F8, даже не прописывая в свойствах таблицы. Просто некогда вылизывать это все до уровня пригодного для других пользователей продукта. Достигаю минимума, который необходим для получения главного и нужного результата и на том останавливаюсь и бегу к следующему вообще неразрешенному вопросу. Из таких вопросов на повестке дня например:
1. Доработать код разделения БД на отдельные файлы вместо единственного.
2. Сделать возможным подключение нескольких БД и работу с любой из них из одного Логпрог. На данном этапе возможно работать только открывая для каждой БД свой отдельный Логпрог. Куча отдельно открытых экземпляров экселя напрягает и не совсем удобно между ними копировать данные через буфер. Инструмент специальная вставка отсутствует.
3. Хочется организовать механизм интеграции баз данных. Т.е возможности показывать несколько БД как продолжение одной логической структуры с возможностью работать с ними как с одной базой.
До тех пор, пока я не реализую подобные задачи, вряд ли у меня найдется время заниматься такими вопросами, как менюшки...

Уже думал об этом. На самом деле это действительно самое страшное. Производитель в любой момент может поставить крест намоем  многолетнем труде, лишив его будущего. Зависимость от MS-Office - да, тяжелая моральная ноша. 16й Офис меня уже раз напугал. Я об этом тему уже делал здесь Очень похоже все на то, что Вы описываете. Но обновлениями за год Майкросовт подлатал продукт так, что большинство глюков месяц-два назад наконец канули в лету. Тем не менее год мучений подобных Вашим мне был обеспечен.

Ну, про замечание ответил там же. Оно было не по делу, т.к код не имел никакой смысловой нагрузки, а показывал отступы. А Вы стали делать замечания по смыслу, которого не было.
Что до мерцания экрана - действителньно - недоработка. Только не концептуальная и не архитектурная, а просто недоделка, которая может быть устранена в любой момент и не вызовет никаких переделок и не нуждается в доработке архитектуры. (Причем, вопрос уже давно был решен в прошлых версиях и только мясяц назад я тронул код, поотключав Screenupdating (я приводил код ранее - Вы можете в нем видеть закомментированные Screenupdating). Мне не сложно их опять включить. Но не до них мне. Таких недоделок действительно уйма. Я их оставляю на потом, потому что они не принципиальны и в любой момент могут быть закрыты, если потребуется. Но опыт говорит о том, что 60% из них и не потребуется переделывать, потому что со временем глобальный подход тоже претерпевает изменения и многие вопросы отпадают всвязи с переделками на более высоком уровне. Для примера, на всем протяжении разработки Логпрога  в голове зреет версия принципиально иной концептуальной реализации внутренней архитектуры. Это повлечет 100% переписывание всей программы. Останутся только наработки - те накопленные инструменты пользователя и принципы управления данными, котрые сформировались благодаря текущей реализации Логпрог.
Возможно, продукт будет в конечном итоге переписываться в другой среде программирования. Поэтому, какая мне разница, что у меня там моргает сегодня? Меня интересуют концептуальные вопросы на данный момент. В данный момент концепция еще не вызрела. Она в развитии. И нет смысла заниматься причесыванием блох на данном жтапе. Это все бесполезная работа. Я использую правило Паретто: 20% усилий дают 80% эффекта. Поэтому продукт хронически недоработан на сегодня.

Alemox, от чего же не покупаю? Я имею возможность купить Электролюкс, а имею возможность Ивушку или Вятку-автомат. Выбор за мною Если мне нужно 80% эффекта - т.е стирку при 20% усилий, то я могу взять для этого Вятку-автомат. А если мне нужны все 100% при соответствующих затратах, то куплю LG.

Вас не осуждают. А интересуются почему сделано именно так и не как по другому.

А есть возможность самому что то окрашивать каким-то цветом. Какой то определённый пункт. Он это запомнит?

Есть вариант к любой таблице просто добавить новую графу на уровне описания типа и использовать ее для пометок какого-то свойства некоторых записей. Это будет альтернатива цветному выделению. Ну на худой конец задать в этой колонке условное форматирование и подсвечивать что-то цветом только в тех записях, где она не пуста.