A few weeks ago, I was looking at the screen of the computer belonging to the occupational psychologist for whom I write programs. The screen was extremely cluttered with icons, in main due to the fact that there were icons for each of the program suites which I have written for her. With ten different suites and two or three icons for each suite, that works out to a lot of icons! I idly suggested writing a program which would manage all of those programs, leaving her with only one icon on the screen. Basically, I was advocating a return to something similar to Windows 3.1 with its program groups.
There are several ways in which I could have implemented this; in the end, I chose an implementation based on the treeview control. This has four levels:
- 0 - the top level, always 'programs'
- 1 - the program group (for example, 'Adjectives')
- 2 - the type of program (administrator, exam, results)
- 3 - the path to the program
It would make things easier if I showed a screen shot of the program. Naturally, almost all of the data are in Hebrew, but as they say, one picture is worth a thousand words.
The program loaded its data via the treeview's 'loadfromfile' method, and of course saved its data with the 'savetofile' method. As opposed to most of my programs, this one has a sizeable main window (the treeview automatically resizes itself to fill the entire area), so I decided to add code which remembers the window's size. This data is stored in the registry. A neat hack.
// code to load a window's size from the registry
ini:= TRegIniFile.create ('\software\nbn');
with ini do
begin
self.Top:= ReadInteger (prog, 'Top', -1);
self.Left:= ReadInteger (prog, 'Left', -1);
self.Height:= ReadInteger (prog, 'Height', -1);
self.Width:= ReadInteger (prog, 'Width', -1);
end;
Yesterday, the psychologist asked whether nodes could appear in different colours; this would make it easier for her secretary to chose the correct programs. I did a certain amount of research via the Internet looking for Delphi code to do this, and it became apparent that I would need to use the 'CustomDrawItem' of the treeview. After a little more work, I discovered that I had already used this method in another program of mine and that it was very simple to do what was necessary. It's sometimes amazing to see how simple Windows code can be in Delphi which seems to be so complicated in other languages:
procedure TMainForm.TVCustomDrawItem(Sender: TCustomTreeView;
Node: TTreeNode; State: TCustomDrawState; var DefaultDraw: Boolean);
begin
with sender.Canvas do
begin
case longint (node.data) of
1: font.color:= clBlue;
2: font.color:= clGreen;
3: font.color:= clRed;
0: font.color:= clBlack
end;
if node.level = 1
then font.style:= [fsbold]
else font.style:= []
end
end;
After successfully displaying node text in colour, I had to decide how the colour of each node would be represented, and how this colour would be stored between invocations. At the moment, the program only recognises three colours (apart from black), and the index to these colours is stored in each node's 'data' property. The value can be chosen in the 'edit program' dialog box which appears whenever the user double clicks on a program title (level 2; double clicking on a node at level 3 will execute the program whose path is displayed). I quickly established that the 'savetofile' method does not save the 'data' property, meaning that I would have to write code to save the data, and then similar code to load the data.
The code to save the data was actually very simple: an ordinary text file is created, and for each node in the tree a line is written, consisting of the node's level, its text and its data, represented as an integer, where null data is equivalent to 0.
assignfile (f, datfilename);
rewrite (f);
for i:= 1 to tv.Items.count do
with tv.items[i-1] do
writeln (f, level, ',', text, ',', longint (data));
writeln (f, '*** end of file'); // dummy line
closefile (f);
Reading in the file and building the tree structure was a bit more difficult. The key to building the tree is to remember that the parent of a node at level 0 will be 'nil' - there is no parent, as this is the top node. The parent of a node at level 1 will be the node at level 0 (which will always be tv.items[0]). Following a node at level 1 will be its sons, and following each son node will be its son nodes; thus all that is necessary is to save a pointer to each node being inserted, and use this node as the father for the next nodes. Nodes at level 2 also have to have their colour restored.
datfilename:= extractfilepath (application.exename) + 'progman.dat';
assignfile (f, datfilename);
{$I-}
reset (f);
{$I+}
if ioresult = 0 then
begin
readln (f, line);
while not eof (f) do
begin
i:= pos (',', line);
level:= strtoint (copy (line, 1, i-1));
line:= copy (line, i + 1, length (line) - i);
i:= pos (',', line);
case level of
0: tv.Items.AddChild (nil, copy (line, 1, i-1));
1: node:= tv.Items.AddChild (tv.items[0], copy (line, 1, i-1));
2: pnode:= tv.Items.AddChildObject (node, copy (line, 1, i-1),
pointer (strtoint (copy (line, i + 1, length (line) - i))));
3: tv.Items.addchild (pnode, copy (line, 1, i-1));
end;
readln (f, line)
end;
closefile (f);
end
else
try
tv.loadfromfile (extractfilepath (application.exename) + 'progman.txt')
except on e: exception do
tv.Items.AddChild (nil, 'Programs');
end;
There is a slight bug in this code: eof (end of file) will be true after the last line of the file has been read, but that line won't get processed because the code exits the loop. Instead of adding duplicate code to process that final line, I decided to add a dummy line to the file which will allow the final line of data to be processed whilst not being processed itself. This is called the 'sentinel' technique.
If the above code can't find its data file (which will be called 'progman.dat'), it looks for a file called 'progman.txt', which was the data file from the previous version of the program. If this file is found, then the tree will be built, albeit with no colours. If this file isn't found, then the program creates a new tree with a dummy first node.