Организация дерева меню

Отделим мух от котлет.
Имеются несколько "деревьев"
1. Иллюстрированные меню программ. Реализованы на XML.
Может быть и один XML, могут быть много. Один большой дольше загружается. Маленькие могут быть вложены один в другой и в памяти образуют одно дерево. Разбивка на маленькие предусмотрена для удобства разборок (свои меню по темам) и для использования одних и тех же пунктов в разных разделах. Например, рисование отметок нужно всем, описаны они в одном маленьком XML, а отображаются у всех специальностей.
Таких файлов не несколько тысяч, а пока 180.
2. Иллюстрированные опции к разным программам. Принцип то же, только выбирается не программа, а данные. Количество - по программам, хотя один и тот же справочник могут использовать разные программы. Например из справочника труб кто-то использует только обозначение, а кто-то и технические характеристики.
3. Классификатор слоев. Здесь использовали много разных вариантов. В книге рассмотрен вариант с описанием свойств слоя в отдельном файле, размещенном в файловой системе. Но рядовой пользователь об этом и не знает. Он видит такое же дерево. Это дерево можно экспортировать в XML или в БД.
Вариант с файловой системой принят на период формирования номенклатуры слоев. Если, например, создан набор слоев для одного этажа, то достаточно просто скопировать каталог в дуругие этажи, а не вводить копированием в файлах.
Потом, после того, как номенклатура устаканится, можно переходить на клиент-серверную технологию.

Нет никаких проблем с деревом в базе. Сайт www.kurganobl.ru/cad/  весь находится в БД и администрирование ведется из специальной программы, отображающей его в виде дерева. Хотя можно и прямо из браузера.
Но текстовыми XML-файлами гораздо удобнее манипулировать и редактировать их. Рассматривайте их как Базу Данных. БД могут быть и текстовые. Сейчас развиваются XML-базы.
Кроме того, реляционные базы в таблицах предполагают неизменную и единую структуру для всех записей. В XML мы можем использовать произвольную структуру для каждого объекта.

Сложного там ничего нет. Простой анализ вложенных узлов. Да и какая разница пользователю, как реализована функция? Ему важно, сложно или нет кнопки нажимать. Варианты пользовательского интерфейса, конечно, могут совершенствоваться.

Объемы данных для масштабов СУБД мизерные. Это же не миллионы позиций, а максимум тысячи. И максимум - десятки клиентов.  Усложнять систему нет никакого смысла. Все может быть организовано и на файл-сервере и на разделяемом ресурсе - в рамках проводимой системной политики.
Хранение данных на удаленном сервере предусматривается более для возможности доступа к ним через Интернет. Для САПР это не очень-то нужно, разве что для стандартизации классификатора слоев. Важнее в ГИС, где много удаленных организаций должны работать с одними данными.

> Евгений, Екатеринбург
В одном файле может быть разное количество "команд", а команда может создавать много вариантов изображений.
Произвольная структура позволяет хранить данные с различными атрибутами (в терминах XML). Создавать разные атрибуты, отображать данные в различном виде. Собственно все, ради чего и был придуман XML.
Преимущества баз данных, особенно клиент-серверных известны. Так же как их недостатки. Программисты часто страдают излишествами - для любых данных непременно БД, да еще клиент-серверную. Тем самым обеспечивают себя работой, так как программы, основанные на СУБД часто без авторов не работают.
Занести каталоги мало. Надо их как-то использовать. А это - разработка софта. Да и не так уж много необходимых материалов. Велика ли и часто ли меняется номенклатура прокатных профилей? Но если они действительно необходимы всем и сразу - конечно надо использовать SQL-субд. И прилагающийся персонал.
Но это уже не меню.

Если я правильно понял, то

TreeView1.Items[62].Selected:=true;