OberonCore

А есть ли где-то описание формата ODC? Т.е. именно формата, а не интерфейсов модулей которые им манипулируют.

Я правильно понимаю, что ODC по сути контейнер в который набивается разнородным содержимым, как например avi, или там какой-нибудь odf?

Собственно меня интересует общий формат ODC, и формат тех сущностей, которые представляют текст (в т.ч. исходник кода на КП). Остальное хотелось бы научиться игнорировать. По кр. мере пока.

Смотрите.

Формат, в котором сериализуются Stores.Store, можно увидеть в Dev/Spec/StoresFileFormat.

ODC-файл - это файл, в который выгружен Documents.Document (а точнее, его конкретная реализация Documents.StdDocument).
Т.е. надо уже смотреть, что он там пишет, какие свои поля.

Далее, этот Document при своей выгрузке записывает основную вьюшку, которая сохранена в документе. В случае текста это будет TextViews.StdView (процедура Externalize). А он уже пишет при своей выгрузке TextModels.StdModel. Которая уже пишет текст.

Вот такая матрёшка.

Однако можно читать текст и "по-тупому", например, именно так сам Блекбокс считывает строковые ресурсы из файлов Rsrc/Strings.

Это делается... в модуле Dialog, процедура ReadStringFile.

Ну, у меня дело усугубляется тем, что мне на последующих этапах ещё и писать/модифицировать odc надо будет. Т.е. в любом случае со структурой разбираться придется, чтобы не сломать.

Напишите и соберите на ББ DLL, которая будет с этим работать, как положено, средствами Framework, а выдавать Вам наружу всё, что захотите.

Да, видимо так будет быстрее всего.

Но даже если и с такой утилитой, я всё не очень хорошо понимаю -- вот сказали мне файл (набор файлов), я их скормил dll'ке. Она мне выдала, по всей видимости, для каждого из файлов некое дерево содержимого. Хорошо. Выкинули оттуда всё то, что не текст. Получили дерево текстовых документов, содержащихся в одном файле. И как моей программулине определить кого из них анализировать (например на предмет рисования графа зависимостей). Пытаться проанализировать всех?

Компилятор ББ работает только с текстом верхнего уровня. Это в общем логично - вложенные тексты обычно служат для иллюстраций и комментариев.

По моему, он работает с текстом текущего уровня, т.е. с тем, что сейчас находится в фокусе.

А ещё есть DevCompiler.CompileSelection который работает с выделением в тексте, который сейчас находится в фокусе. Ваша задача всё усложняется

А если говорить серьёзно, то компилятор работает с тем текстом, который ему скормят, игнорируя любые вложения. И есть набор команд, которые берут тексты из "разных мест".

В разработке обычно используется Compile, которая вызывается для корневого документа, и CompileThis которая отрабатывает список "корневых текстов" из документов.

CompileSelection или компиляция (при пом. Compile) вложенного текста - это редкие случаи, которые (насколько я встречал) используются только для иллюстраций и примеров.

В принципе да, вначале может идти просто текст, а потом уже исходник, чтобы скомпилировать его пользователь просто выделит исходник и собственно скажет "скомпилируй мне".

Но для меня это уже не важно

Для ещё большего усложнения задачи напомню о DevSelectors и StdFolds. И возможности управления селекторами при компилировании