Все что нужно сделать для использования потока - это инициализировать его. Точный синтаксис конструктора Init может быть разным, в зависимости от типа потока, с которым вы имеете дело. Например, если вы открываете поток DOS, вам нужно передать имя файла DOS и режим доступа (только чтение, только запись, чтение/запись) для содержащего поток файла.

    Например, для инициализации буферизированного потока DOS при загрузке набора объектов в программу, все что вам нужно это:

     var
       SaveFile: TBufStream;
     begin
       SaveFile.Init('COLLECT.DTA', stOpen, 1024);
        .
        .

    После инициализации потока все готово к работе.

    TStream это абстрактный механизм потока, поэтому вы будет работать не с ним, а с производными от TStream удобными объектами потока. Это будет, например, TDosStream, для выполнения дисковых операций ввода-вывода, TBufStream для буферизованных операций ввода-вывода (очень удобен для частых операций считывания или записи небольших объемов информации на диск) и TEmsStream для передачи объектов в память EMS. Кроме того, ObjectWindows реализует индексированные потоки с указателем, указывающим место в потоке. Перемещая этот указатель вы можете организовать произвольный доступ в потоке.

    Давайте сначала рассмотрим процедуру Put. Общий синтаксис метода Put следующий:

     SomeStream.Put(PSomeObject);

    Специальный интерес для вас, как для программиста, работающего с ObjectWindows, состоит в том факте, что при помещении в поток группы с дочерними окнами, дочерние окна также автоматически помещаются в поток. Таким образом, запись сложных объектов не так уж и сложна, более того, это делается автоматически! Вы можете сохранить полное состояние диалога простым помещением объекта диалога в поток. При повторном запуске вашей программы и загрузке диалога будет выведено его состояние в момент записи.

    Считывание объектов из потока столь же просто. Все что вам нужно сделать, это вызвать функцию Get:

     PSomeObject := SomeStream.Get;

где SomeStream - это инициализированный поток ObjectWindows, а PSomeObject - указатель на некоторый тип объекта ObjectWindows. Get просто возвращает указатель на нечто, что он взял из потока. Сколько данных было взято и какой тип таблицы виртуальных методов (VMT) присвоен данным, определяется не типом PSomeObject, а типом объекта, обнаруженным в потоке. Следовательно, если объект в текущей позиции SomeStream имеет не совпадающий с PSomeObject тип, у вас будет некорректная информация.

    Как и Put, Get ищет сложные объекты. Следовательно, если вы ищите в потоке окно, которое владеет дочерними окнами, то они также будут загружены.

    И, наконец, процедура Error определяет что происходит при возникновении ошибки потока. По умолчанию TStream.Error просто устанавливает значение двух полей в потоке (Status и ErrorInfo). Если вы хотите сделать что-либо более содержательное, например, сгенерировать соответствующее сообщение о сбое в работе программы или вывести блок диалога c сообщением об ошибке, то вам нужно переопределить процедуру Error.

как для уничтожения объекта потока, так и для его закрытия.

    Все что было добавлено к данным окна - это одно булевское поле. Для загрузки объекта вы просто считываете стандартный TWindow, а затем считываете дополнительный байт булевского поля. Типичные методы Load и Store для производных объектов будут выглядеть следующим образом:

     constructor TMagritte.Load(var S: Stream);
     begin
      TWindow.Load(S);                          { загрузка типа }
      S.Read(Surreal, SizeOf(Surreal));         { чтение
                                           дополнительных полей }
     end;

     procedure TMagritte.Store(var S: Stream);
     begin
      TWindow.Store(S);                       { сохранение типа }
      S.Write(Surreal, SizeOf(Surreal));      { запись
                                           дополнительных полей }
     end;

    Вы должны контролировать, что записывается и загружается один и тот же объем данных, и загрузка данных производится в той же последовательности, что и их запись. Компилятор не покажет ошибки. Если вы будете недостаточно аккуратны, то могут возникнуть серьезные проблемы. Если вы изменяете поля объекта, то нужно изменить и метод Load, и метод Store.

    По соглашению всем регистрационным записям потока ObjectWindows присваивается то же имя, что и соответствующим типам объектов, но начальное "T" заменяется на "R". Следовательно, регистрационная запись для TCollection будет иметь имя RCollection. Такие абстрактные типы как TObject и TWindowsObject не имеют регистрационных записей, поскольку их экземпляры вы никогда не будете хранить в потоках.

    Поля Load и Store содержат соответственно адреса методов Load и Store.

     RSomeObject.Load := @TSomeObject.Load;
     RSomeObject.Store := @TSomeObject.Store;

    Значение последнего поля, Next, задается RegisterType и не требует никакого вмешательства с вашей стороны. Оно просто обеспечивает внутреннее использование скомпонованного списка регистрационных записей потока.

    Вот и все. Теперь вы можете помещать (Put) экземпляры вашего нового типа объекта в любой поток ObjectWindows и считывать их из потоков.

    Реализация метода Store вполне очевидна. Каждый объект вызывает свой унаследованный метод Store, который хранит все унаследованные данные. Затем вызывается метод Write для записи дополнительных данных:

     procedure TGraphObject.Store(var S: TStream);
     begin
       S.Write(Rect, SizeOf(Rect));
     end;
     procedure TGraphPie.Store(var S: TStream);
     begin
       TGraphObject.Store(S);
       S.Write(ArcStart, SizeOf(ArcStart));
       S.Write(ArcEnd, SizeOf(ArcEnd));
     end;

    Обратите внимание, что метод TStream Write делает двоичную запись. Его первый параметр может быть переменной любого типа, но TStream.Write не может узнать размеры этой переменной. Второй параметр содержит эту информацию, и вы должны придерживаться соглашения относительно использования стандартной функции SizeOf. Таким образом, компилятор всегда может гарантировать, что вы всегда считываете и записываете нужное количество данных.

    Вам не нужно регистрационная запись для TGraphObject, так как это абстрактный тип, и он никогда не будет помещаться в набор или в поток. Указатель Load каждой регистрационной записи устанавливается в nil, поскольку в данном примере рассматривается только помещение данных в поток. В следующем примере методы Load будут определены, и изменены регистрационные записи (см. STREAM2.PAS).

    Обратите внимание, что вам нужно зарегистрировать TCollection (используя его запись RCollection - теперь вы видите, что соглашения о присваивании имен упрощают программирование), хотя вы и не определили TCollection. Правило очень простое и незабываемое именно вы отвечаете за регистрацию каждого типа объекта, который ваша программа будет помещать в поток.

    В результате создастся файл на диске, который содержит всю информацию, необходимую для "считывания" набора назад в память. Когда поток открыт, и ищется набор, то (см. STREAM2.PAS) "магически" восстанавливаются все скрытые связи между набором и его элементами, объекты и их таблицы виртуальных методов. Следующий раздел поясняет, как помещать в поток объекты, которые содержат связи с другими объектами.

    Давайте рассмотрим, чем этот метод Store отличается от обычного Store. После обычного сохранения окна все что нам нужно сделать, это записать ссылку на поле Msg, вместо записи самого поля, как мы это обычно делали. Действительный объект кнопки хранится в виде дочернего окна для окна, которое вызывается TWindow.Store.

    Кроме этого нужно поместить эту информацию в поток с указанием того, что Msg указывает на это дочернее окно. Метод Load производит обратные действия, сначала загружая окно и его дочернее окно командной кнопки, а уже затем восстанавливая указатель на это дочернее окно через Msg.

    Единственно о чем нужно побеспокоиться, так это о загрузке ссылок на родственные окна, которые еще не загружены (т.е. в списке дочерних окон они идут ниже и, следовательно, позднее в потоке). ObjectWindows автоматически обрабатывает эту ситуацию, отслеживая все подобные будущие ссылки и разрешая их после загрузки всех дочерних окон. Вам нужно иметь в виду, что родственные ссылки не будут действовать, пока Load не выполнится целиком. Принимая это во внимание, вы не должны помещать в Load никакой код, который использует дочерние окна, которые зависят от их родственных окон, поскольку в этом случае результат может быть непредсказуемым.