Текущий раздел:

Описания RDS

Руководство программиста

Глава 2. Создание моделей блоков

§2.8. Сохранение и загрузка параметров блока

§2.8.1. Способы хранения параметров блока

# Руководство программиста

## Глава 2. Создание моделей блоков

### §2.8. Сохранение и загрузка параметров блока

Рассматриваются процедуры сохранения и загрузки личных параметров блока в файле схемы. Описывается более простой двоичный способ сохранения и более сложный – текстовый. Для текстового режима приводятся разные способы хранения данных: формат с ключевыми словами и формат, аналогичный стандартным INI-файлам («имя=значение»). Рассматриваются вспомогательные объекты RDS, упрощающие разбор текста.

#### §2.8.1. Способы хранения параметров блока

Рассматриваются двоичный и текстовый форматы хранения личных данных блока в файле или буфере обмена, указываются преимущества и недостатки обоих форматов.

Если какие-либо настроечные параметры блока хранятся в его личной области данных, модель должна сама позаботиться об их записи при сохранении схемы, добавлении блока в библиотеку или копировании его в буфер обмена. Можно, конечно, хранить параметры в тексте комментария блока или в значениях по умолчанию статических переменных, как было сделано в примерах в §2.6.3 и §2.7.4 – эти значения RDS сохраняет самостоятельно. Однако, это не всегда удобно. Комментарий блока может быть изменен пользователем, не знающим, что модель блока использует его для своих целей, а при хранении параметров в значениях переменных по умолчанию придется ограничиваться набором типов, используемых в RDS. Значения по умолчанию хорошо подходят для хранения простых параметров, например, чисел double и int. Если же параметры имеют сложную структуру, и, к тому же, не предполагается, что пользователь захочет устанавливать значения этих параметров по связям от других блоков, лучше всего хранить их в личной области данных. При этом можно использовать любые типы переменных: структуры, массивы структур, битовые флаги и т.п, и обращаться к ним как к обычным переменным языка C. Конечно, в переменных блока тоже можно было бы организовать, например, массив структур, но хранить в его значениях по умолчанию настроечные параметры не получится – в RDS у всех элементов массива будет одно общее значение по умолчанию.

RDS сохраняет схемы и блоки в одном из двух форматов: в двоичном или в текстовом. Данные в двоичном формате, как правило, занимают меньше места и быстрее загружаются, при этом часть модели блока, отвечающую за загрузку и сохранение данных, можно сделать очень простой – достаточно записать подряд все параметры блока при сохранении схемы или блока, а при загрузке считать их в той же последовательности. Данные в текстовом формате занимают больше места, обрабатываются несколько дольше, и модель блока получается более сложной – необходимо анализировать текст, отыскивая в нем параметры блока (например, по ключевым словам). Однако, в текстовом формате проще обеспечить совместимость новых версий моделей с данными, сохраненными старыми версиями. При изменении структуры параметров блока загрузка старой схемы в двоичном формате, вероятнее всего, вызовет ошибки из-за несоответствия списка параметров, сохраненных предыдущей версией модели, списку, которую попытается загрузить новая версия. Например, если старая версия модели сохраняла два числа double и одно число int (итого 2×8+4=20 байтов), а новая – три числа double и одно число int (3×8+4=28 байтов), то данные, записанные старой версией при сохранении схемы, новой версией модели будут загружены неправильно. В текстовом формате такой проблемы обычно не возникает – параметры блока чаще всего опознаются по ключевым словам, и те параметры, которые отсутствовали в старой версии модели, просто не будут загружены и сохранят значения по умолчанию, поскольку соответствующие им ключевые слова при загрузке старой схемы просто не встретятся. Конечно, двоичный формат тоже можно сделать достаточно гибким, например, присвоив каждому параметру блока уникальный код и записывая пары «код-значение». Однако, при этом теряются основные достоинства двоичного формата – скорость загрузки и простота реализации, поскольку теперь при загрузке придется анализировать код и тип каждого параметра. Кроме того, схема, сохраненная в текстовом формате, может быть просмотрена и отредактирована в любом текстовом редакторе, что значительно упрощает отладку моделей (всегда можно посмотреть, правильно ли записались параметры блока) и позволяет, при желании, обрабатывать схемы какими-либо внешними программами, которые могут работать с текстовыми файлами (например, искать в файле схемы какое-нибудь слово или сочетание слов при помощи программы «grep»).

В данный момент двоичный формат используется в RDS только при копировании блоков через буфер обмена, поскольку при этом не нужно обеспечивать совместимость с устаревшими версиями библиотек. Начиная с версии 1.0.123 схемы и блоки всегда сохраняются в текстовом формате.

В модель блока, настроечные параметры которого хранятся в личной области данных, достаточно добавить функции сохранения и загрузки этих параметров только в одном из форматов. Формат, в котором сохраняет свои данные модель, не обязательно должен соответствовать формату, в котором RDS сохраняет схему или блок. При сохранении схемы или записи блока в библиотеку модель блока сначала вызывается для сохранения данных в том формате, в котором сохраняется весь файл, то есть в текстовом. Если в результате вызова модели были сохранены какие-либо данные, RDS считает, что модель поддерживает этот формат, и не предпринимает никаких дополнительных действий. Если же данные не были сохранены, RDS снова вызывает модель, но уже для сохранения данных в двоичном формате, после чего записанные моделью данные приводятся в соответствие с требованиями текстового формата. Сохраненный моделью массив двоичных данных переводится в набор шестнадцатеричных чисел и записывается в файл в виде текста «dlldata data размер_массива набор_чисел». При копировании одного или нескольких блоков в буфер обмена RDS сначала вызывает модель для сохранения данных в двоичном формате. Если модель ничего не сохранила, RDS будет считать, что двоичный формат не поддерживается моделью, и она будет вызвана еще раз для записи в текстовом формате. Текст, который она записала, будет добавлен в буфер обмена как массив байтов.

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

Чаще всего в моделях реализуют только текстовый формат загрузки и записи параметров как наиболее гибкий. Двоичный формат обычно используют для несложных блоков, которые разрабатываются для какой-либо конкретной схемы и которые не предполагается включать в библиотеки. В принципе, можно сделать в модели сохранение данных в обоих форматах, но на практике так поступают редко – раз более сложный текстовый формат уже поддерживается, нет необходимости добавлять в модель поддержку двоичного.