Первоначально я хотел рассмотреть написание оболочки как пример использования Dev Express, но позже передумал. Ибо это тянет на отдельный цикл статей, и теперь они перед вами!
Итак, зачем собственно переписывать то, что и так неплохо работает?
1) Поиск: меня абсолютно не устраивает быстродействие и возможности поиска
2) До недавнего времени у меня был не самый мощный компьютер, поэтому хотелось чтобы оболочка стартовала быстрее
3) Перегруженный и абсолютно не эргономичный интерфейс
4) Пара досадных багов и ненужные понты разработчика
— Как же можно решить озвученные мною проблемы?
— Использовать для хранения статей базу данных!
Проектирование базы данных
Самым рациональным будет использование файл-серверной MS ACCESS и даже не
пытайтесь меня отговорить. Не будем создавать ничего лишнего, поэтому таблиц будет всего две: в первой храним статьи, во второй — категории. Как пользоваться аксессом – читайте книжки. Теорию реляционных баз данных ищите
в них же. 
Собственно вот моя структура:
Обратите внимание, что ключевое поле категории не является счетчиком! Почему так – будет объяснено ниже.
Не понимаете, зачем нужен родитель и что это вообще такое? Да вот:
Как видно, родителем у категории «Dot Net» будет «Программа и Интерфейс».
Одной из особенностью нашей программы будет использование неограниченных
вложенностей категорий, в отличии от DW, где их всего две (почитайте про бинарные деревья).
Импорт статей
Это один из главнейших вопросов. Загрузить все статьи целиком не представляет сложности, но разбить их по категориям… Ну уж нет, лучше попытаться найти место, где хранится список связей. Ларчик открывался совсем просто, но начнем по порядку. Заходим в папку base, где лежит очень очень много файлов и ищем menu.list. В этом файле содержится список первых 3000. Открываем с помощью текстового редактора (я делаю это блокнотом). Формат такой: если перед словами нет ни одного отступа (табуляции), то это корневая категория, если 1 отступ – подчиненная первой. Ну а если два, то это уже название самой статьи. А файлик, который с ней связан, идет после
разделителя.
Смешно, не так ли? Думаю, теперь вам ничего не мешает написать процедуру импорта, анализируя этот файл. Чтобы помочь в этом деле привожу блок-схему
добавления/изменения одной статьи или категории:
Не буду приводить листинг процедуры, чтобы не загромождать текст, а сделаю лишь пару замечаний:
— в начале открываем файл menu.list вручную. Естественно, в финальном варианте пользователю ничего такого делать не придется.
— предполагается, что открытый файл находится в папки Base проекта DW.
— если в базе уже есть категория или статья, то диалога о замене не будет (ради упрощения кода).
— переменные idRoot и idCategory служат для хранения последних встретившихся категорий, причем не важно, добавленных или нет.
— обратите внимание на переменную CategoryCounter и константу CategoryK.
При построении дерева, мы будем использовать запрос, объединяющий таблицы (union), поэтому все id должны быть уникальными. Если для статей поля является счетчиком, то для категорий мы должны высчитывать его вручную. Константа как раз и определяет минимально значение (я взял его побольше, чтобы наверняка исключить совпадение), а в переменной хранится текущее, которое будет присвоено новой записи и тут же увеличено на единицу.
— в списке импорта у нескольких статей после имени файла имеется символ табуляции.
Вы можете попытаться найти такие статьи и удалить его сами, либо взять уже
исправленный мною файл.
Помните, что в основном статьи будут загружаться всего один раз, поэтому не стоит относиться к быстродействию процедуры с фанатизмом. Код можно улучшить (например, вместо загрузки всего списка статей читать текстовый файл по строчке с помощью Readln, убрать проверки существования файла, модифицировать алгоритм, использовать вместо метода locate что-нибудь другое и т.д.).
Импорт дополнительных статей
Что дальше? А дальше нужно загрузить оставшиеся статьи. Этот список хранится в файле new_articles.txt и имеет уже чуть другой формат: файл статьи | корневая категория | подкатегория | название статьи.
Я не буду комментировать только что сказанное: что толку требовать от бесплатной программы? Но теперь понятно, почему вложенность составляет всего 2 категории. В реализации алгоритма ничего сложно нет, единственное замечание: в списке есть новые подкатегории — нужно будет делать дополнительные проверки на существовании их и, если их нет, то добавлять.
Заключение
Проведя успешно импорт, проверим, насколько он удался. В dw 11 категорий и 197 подкатегорий.
У нас также 11 категорий:
И 194 подкатегории:
Куда делись 3 подкатегории? Посмотрите на построенное дерево:
В корневых категориях «Рабочий стол», «Синтаксис» и «Технологии» существуют категории, с аналогичными названиями, поэтому они не добавились. Для решения этой проблемы достаточно подправить либо название корневой категории (только в menu.list), либо имена дочерних (и в menu, и в new_articles).