Двоякий исследователь

Проблема Исследователя  в том, что он один, а используется для двух целей: как меню и как краеугольный камень на котором держится наша система разграничения прав доступа. В результате, простейшую задачу: скрыть от пользователя ненужные ему разделы, решить не так-то и просто. Убрать право на просмотр для ненужных ветвей и команд? Но тогда, из-за отсутствия прав доступа, перестанут работать многие внутренние алгоритмы и макросы.

Очевидно,  что презентационная часть должна быть отделена от системы разграничения прав. Заодно и визуальную организацию следует пересмотреть. Древовидный список — это, конечно, самое простое и первое, что приходит на ум, но, работать с базой на которую загружено много прикладных настроек, через Исследователь неудобно. Так как команд даже в одном разделе Исследователя, как правило, достаточно много, их следует развернуть в двухмерную сетку. Тогда напрашивается организация Исследователя ввиде набора вкладок, где каждая вкладка — это раздел. На вкладке выводим пиктограммки команд. Их тоже группируем, уже по подразделам. Например: вкладка "Зарплата". На ней несколько визуально выделенных областей: документы, справочники, отчеты, параметры и т.д.

Где-то вверху исследователя должна располагаться строка поиска. Вводим в ней последовательность символов и получаем все найденные команды, отсортированные по релевантности. Сначала показываем по вхождению в наименование самой команды, потом по вхождению в наименование раздела, в который входит команда и т.д. по иерархии разделов-подразделов в GD_COMMAND.

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

Известная истина гласит: все новое — это хорошо забытое старое. Если мы выводим пиктограммки команд в двухмерной сетке, да еще и визуально разделяем их по областям, то почему бы не нарисовать связи между ними? Что бы начинающему пользователю сходу было понятно что к чему. Рисуем и получаем...

Центр управления™ из нашей старой доброй программы Анжелика Бухгалтер!

В свое время, для отрисовки Центра управления был написан renderer, который принимал на вход особый двоичный код. Код хранился в *.RC файле и компилировался прямо в выполняемый модуль. Не очень удобочитаемый был код, надо сказать:

22 GSTOOLBAR
BEGIN
28
111
20
0
529
$04
$00
1
0
0
$04
$01
0
1
102
$04
$00
2
2
333
$08
$00
3
3
...

PS: Ради справедливости стоит заметить, что идея центра управления была подсмотрена нами 15 лет назад в австралийской программе MYOB.