Articles   Members Online:
-Article/Tip Search
-News Group Search over 21 Million news group articles.
Member Area
-Account Center
-Top 10 NEW!!
-Submit Article/Tip
-Forums Upgraded!!
-My Articles
-Edit Information
-Become a Member
-Why sign up!
-Chat Online!
-Indexes NEW!!
-Build your resume
-Find a job
-Post a job
-Resume Search
-Link to us
Visit Embarcadero
Embarcadero Community
Implementing object persistence using streams Turn on/off line numbers in source code. Switch to Orginial background IDE or DSP color Comment or reply to this aritlce/tip for discussion. Bookmark this article to my favorite article(s). Print this article
Delphi 2.x
User Rating
No Votes
# Votes
DSP, Administrator
Reference URL:
			Author: Lou Adler

How do I save data entered in a list box at run time without resorting to a text 
file or having to deal with the overhead of a table?


This question actually asks much more than just saving a list box at runtime. It 
brings to the surface some of the internal workings of Delphi itself. But I should 
clarify that what I present here does not deal with the workings of Delphi's 
Runtime Type Information (RTTI). That's probably best left for another article. But 
what I'm going to discuss is a practical way of implementing object persistence in 
your programs by using the saving the of a listbox at runtime as an example. Okay, 
here we go...

Any OOP class library worth its salt supports what is called streamable persistent 
objects. Simply put, this means that an instance of a class (or at least its data) 
can be saved to a disk file and restored later. When a program reloads the object, 
it is restored in its last state, just prior to being written. The cool thing about 
this is that the program doesn't have to have any advance knowledge of the state of 
the object; the object itself contains all the information it needs to recreate 
itself when it's restored.

For example, let's say you've created a program that has a list box in which people 
append various bits of information at run time. For many folks, saving the 
information to disk means iterating through all the items in the list and writing 
them to a text file or even a table. The program must reload the data from the 
external file and add the data, line by line. This is not so bad, but it can be a 
bit of a chore to write the code.

On the other hand, using object persistence, the same program mentioned above 
instructs the list box to write its data to a disk file of some sort. When it wants 
to reload the object, all it has to do is stream it back into memory and specify 
the base class to write to. Remember, since all the data of the object was saved 
with it when it was written to disk, the object comes back to life in its original 
form. That's the whole idea behind object persistence.

Delphi itself makes heavy use of object persistence. Every time you save a project, 
it streams out to disk the data contained in your objects' properties so that 
everything you set during your session is saved. When you reload a project, Delphi 
streams the object data back into your form(s) to restore everything you previously 
set. In fact, a form file itself is streamed to and from disk. I should note here 
that Delphi uses a couple of specialized stream classes, TWriter and TReader which 
are derived from a superclass called TFiler. I won't go into the details of these 
classes here, since I'm providing a much simpler demonstration of employing object 
persistence in your programs. I'll leave it up to you to research this topic 

Moving on, you might ask, "Where does employing streamable persistent objects come 
in handy?" The most useful cases I've found for employing them are when I've 
written programs that provide parameter or input criteria for processes, where the 
range of possible values to search on remain fairly constant from one run of the 
program to the next.

For instance, in my line of work, almost all of my programs are typically 
front-ends to very complex query operations. However, the range of domains and 
their values don't change very often, and from client to client, the same questions 
are typically asked. So in these cases, I've found that simply streaming my 
criteria objects (these are all list objects) out to disk when I close the forms 
and streaming them back in when I open the forms provides a much cleaner solution 
to saving my criteria sets from session to session. Besides, this is very low 
overhead programming, since once the programs are finished with the streams, 
they're immediately destroyed. Not only that, I don't have to use DB.PAS or 
DBTables.PAS for data operations.

A simple example

The example I've provided here is by no means a full-fledged search program of the 
type I normally write. I've merely taken the parts pertinent to this article for 
your use. Feel free to include or modify this code to your heart's content. In any 
case, here's the code listing for the main form of the program. We'll discuss 
particulars below.

unit main;


1   uses
2     Windows, Messages, SysUtils, Classes, Graphics,
3     Controls, Forms, Dialogs, StdCtrls;
5   type
6     TForm1 = class(TForm)
7       ListBox1: TListBox;
8       Edit1: TEdit;
9       Memo1: TMemo;
10      procedure Edit1KeyPress(Sender: TObject; var Key: Char);
11      procedure FormCreate(Sender: TObject);
12      procedure FormClose(Sender: TObject; var Action: TCloseAction);
13      procedure ListBox1DblClick(Sender: TObject);
14    private
15      { Private declarations }
16    public
17      { Public declarations }
18    end;
20  var
21    Form1: TForm1;
23  implementation
25  {$R *.DFM}
27  procedure TForm1.Edit1KeyPress(Sender: TObject; var Key: Char);
28  begin
29    if Key = #13 then
30    begin
31      Key := #0;
32      ListBox1.Items.Add(Edit1.Text);
33      Edit1.Text := '';
34    end;
35  end;
37  procedure TForm1.FormCreate(Sender: TObject);
38  var
39    strm: TFileStream;
40  begin
41    if FileExists('MyList.DAT') then
42    begin
43      strm := TFileStream.Create('MyList.DAT', fmOpenRead);
44      strm.ReadComponent(ListBox1);
45      strm.Free;
46    end;
47  end;
49  procedure TForm1.FormClose(Sender: TObject; var Action: TCloseAction);
50  var
51    strm: TFileStream;
52  begin
53    strm := TFileStream.Create('MyList.DAT', fmCreate);
54    strm.WriteComponent(ListBox1);
55    strm.Free;
56  end;
58  procedure TForm1.ListBox1DblClick(Sender: TObject);
59  begin
60    ListBox1.Items.Delete(ListBox1.ItemIndex);
61  end;
63  end.

You were expecting some complex code, weren't you? In actuality, this stuff is 
incredibly simple. So why isn't it documented very well? I'd say it's because this 
is one of the more uncommon things done in Delphi. But for those of you who wish to 
really get into the innards of the environment, this stuff is a must to understand 
and master. Let's look a little deeper into the code.

The program consists of a form with a TEdit and a TListBox dropped onto it. It has 
just two meaningful methods: FormCreate and FormClose. In the FormCreate method,

64  procedure TForm1.FormCreate(Sender: TObject);
65  var
66    strm: TFileStream;
67  begin
68    if FileExists('MyList.DAT') then
69    begin
70      strm := TFileStream.Create('MyList.DAT', fmOpenRead);
71      strm.ReadComponent(ListBox1);
72      strm.Free;
73    end;
74  end;
76  the program checks for the existence of MyList.DAT with a call to FileExists, which 
77  is the stream file that holds the list box information. if it exists, the file is 
78  streamed into ListBox1; otherwise, it does nothing. with the FormClose method,
80  procedure TForm1.FormClose(Sender: TObject; var Action: TCloseAction);
81  var
82    strm: TFileStream;
83  begin
84    strm := TFileStream.Create('MyList.DAT', fmCreate);
85    strm.WriteComponent(ListBox1);
86    strm.Free;
87  end;

the program writes ListBox1 out to MyList.DAT, overwriting any previous versions of 
the file.

That's all there is to this program. Surprisingly, this is one of the more simple 
things to do in Delphi, but paradoxically it's one of the most difficult things to 
find good information about in the manuals or help file. Granted, as I mentioned 
above, doing this type of stuff is fairly uncommon, but think of the implication: 
simple, low overhead, persistent storage without the need for tables. What was 
accomplished above was done in fewer than 10 lines of code &mdash that's absolutely 

I urge you to play around with this technique and apply it to other things. I think 
you'll get a lot of mileage out of it.

A demonstration program is available

Vote: How useful do you find this Article/Tip?
Bad Excellent
1 2 3 4 5 6 7 8 9 10


Share this page
Download from Google

Copyright © Mendozi Enterprises LLC