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?
Answer:
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
further.
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;
interface
1 uses
2 Windows, Messages, SysUtils, Classes, Graphics,
3 Controls, Forms, Dialogs, StdCtrls;
4
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;
19
20 var
21 Form1: TForm1;
22
23 implementation
24
25 {$R *.DFM}
26
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;
36
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;
48
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;
57
58 procedure TForm1.ListBox1DblClick(Sender: TObject);
59 begin
60 ListBox1.Items.Delete(ListBox1.ItemIndex);
61 end;
62
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;
75
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,
79
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
incredible!
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 availablehttp://www.delphicorner.f9.co.uk/files/persist.zip.
|
