Это делается с помощью ключевого свойства default:

type TMyEnumeration = (meOne, meTwo, meThree); property MyProp: TMyEnumeration read FMyProp write MyProp default meOne;

Для приведённого примера свойство MyProp не будет записываться в поток в том случае , если для сериализуемого объекта его значение будет равно meOne. Когда таких свойств много, использование default может существенно сократить размер файла и сделать его гораздо изящнее на вид (в dfm-формате).

Используя слово default, важно не допустить одной ошибки. Нужно чётко осознать, что слово default не имеет никакого отношения к инициализации экземпляров класса. Если, предположим, для значения по умолчанию вы выбрали нечто, отличное от нуля или первого элемента enumerated-типа, то в конструкторе класса нужно сделать так, чтобы эти значения присваивались свойствам объекта на этапе инициализации. Иначе получится неприятная вещь: при сериализации объекта значение свойства не будет сохранено в поток. При десериализации оно, соответственно, не прочитается и будет иметь значение, полученное при инициализации (или нулевое значение).

Итак, мы увидели, как сериализуются примитивные типы. В большинстве случае в нас устроят и они, но что делать, если мы хотим сохранить, например, ссылку на другой объект? Хотя ссылка – это 32-битное значение, сохранять его в поток не имеет смысла, поскольку после восстановления объектов из потока, они, конечно, займут совершенно иные адреса в памяти. Кроме того, выше мы говорили только о корневом объекте и не рассматривали варианты, при которых он может «захватить» в процесс сериализации другие объекты. Наследники TPersistent

Первый такой случай имеет место, когда свойство объекта содержит ссылку на объект, унаследованный от TPersistent, но не TComponent, входящий в композицию с сериализуемым. ПРИМЕЧАНИЕ

Если я говорю «объект B входит в композицию с A», я имею в виду, что в A имеется ссылка на B, и что B создаётся и разрушается вместе с A.

Как и в случае с корневым объектом, при сериализации объектов-наследиков TPersistent в поток сохраняется и может быть восстановлена та и только та информация, которая либо содержится в read/write published-свойствах объекта, либо способ записи и чтения которой определён в псевдосвойствах.

Рассмотрим пример. Если мы исследуем реализацию класса TControl = class(TComponent), то увидим, что его свойство Font ссылается на переменную FFont:TFont. Как известно, TFont = class (TPersistent), а в конструкторе TControl мы имеем FFont := TFont.Create; в деструкторе же – FFont.Free.

Если посмотреть на текст, скажем, сериализованной формы (TForm унаследован от TControl), можно заметить, что свойству Font не присваивается значение нового объекта TFont. Вместо этого происходит инициализация уже имеющегося экземпляра:

object Form1: TForm1 . . . Font.Charset = DEFAULT_CHARSET Font.Color = clWindowText Font.Height = -11 Font.Name = 'MS Sans Serif' . . . end

Charset, Color, Height, Name – всё это read/write published-свойства класса TFont.

У этого способа, хоть он и даёт нам возможность «вовлечь» в сериализацию другой объект, есть серьёзное ограничение: так можно сериализовать лишь объекты, находящиеся с данным в отношении «один к одному». Если же корневой объект ссылается на переменное число объектов, этот способ непригоден. Коллекции

В этом случае нам помогают коллекции. Как известно, в VCL есть два класса: TCollection и TCollectionItem (оба – наследники TPersistent), предназначенные служить в качестве базовых для наших собственных коллекций и их элементов. Заводя свою коллекцию, мы должны, как минимум, переопределить конструктор TCollection (так, чтобы он получал правильную ссылку на класс элементов коллекции), метод TCollection.Add и свойство TCollection.Items, чтобы они возвращали нам объекты нужного типа. Коллекции Delphi по сути своей предназначены для того, чтобы реализовывать свойства, хранящие какие-либо списки. А если свойство даёт нам ссылку на коллекцию, которая входит в композицию с сериализуемым объектом, то каждый из элементов коллекции будет сериализован, как наследник TPersistent, т.