Das ist das Problem, was ich hier (und in anderen Foren) immer wieder sehe.
Viele Anfänger, machen sich nicht mal ansatzweise die Mühe, über ihr Problem nachzudenken, es zu analysieren und zu überlegen, was sie überhaupt machen müssen. Es gibt ja ein Forum, wo man einfach mal nachfragen kann und irgendjemand programmiert das dann schon fertig. Klar, für die Hausaufgaben mag das reichen, aber so jemanden will ich dann bitte nicht als Praktikanten bei mir im Büro sitzen haben :-(
Was ist so schwer daran?
Ein Telefonbuch sollte man aus jedem Handy und auch aus vielen anderen Telefonen kennen. Da gibt es mehrere Einträge, die im einfachsten Fall jeweils aus Name und Nummer bestehen, mittlerweile bei vielen Handies aber auch aus viel viel mehr Einzeldaten.
Punkt 1: Ich brauche irgend etwas, um einen zusammengehörigen Satz von Daten (Name, Nummer, Schmachtfaktor) abzuspeichern. Das nennen wir mal einen Datensatz.
Punkt 2: Ich werde mehrere solcher Datensätze abspeichern müssen. Hier kann man sich überlegen, ob man eine feste Anzahl vorgeben soll (ja, damals gabs Handies mit genau 20 Speicherplätzen ;-) oder eine variable Anzahl erlauben möchte.
Weiter gehts: Was will ich mit meinen Daten denn überhaupt machen?
1) Ich will Telefonnummern (Datensätze) eingeben
2) Ich will Telefonnummern (Datensätze) angezeigt bekommen
3) Ich will nach Telefonnummern suchen können (z.B. anhand des Namens)
4) Ich will die Liste der Telefonnummern abspeichern können, so dass ich sie beim nächsten Programmstart wieder einlesen kann
So, nu hab ich schonmal eine Reihe von Anforderungen.
Gehen wir zurück zu Punkt 1: Ich brauch "irgendwas", um einen Datensatz zusammenhalten zu können. Das einfachste Konstrukt, was Delphi uns da bietet, ist der Record:
Delphi-Quellcode:
TEintrag = record
Name: String;
Nummer: String;
end;
Wir werden später sehen, dass der einfachste Weg nicht immer der beste ist.
Um mehrere Einträge innerhalb des Programms verwalten zu können, brauche ich "irgendwas", um mehrere Records zusammenzufassen. Das einfachste Konstrukt, was Delphi uns da bietet, ist das Array:
TTelefonbuch = array[1..20] of TEintrag;
Wir werden später sehen, ....
Jetzt habe ich hier die Variante mit fester Anzahl von Einträgen. Unschön. Es gibt ein sogenanntes variables Array, dessen Länge ich später (also während das Programm läuft) auch noch verändern kann:
Delphi-Quellcode:
type
TTelefonbuch = array of TEintrag;
var
Telefonbuch: TTelefonbuch;
begin
SetLength(Telefonbuch, 20);
...
Leider ist dieses Konstrukt sehr unschön, wenn man viele Einträge hat und sie sich Anzahl immer mal wieder verändert: Delphi muss dann immer einen ganz neuen Speicherbereich anfordern (Ja, es gibt Ausnahmefälle) und dann alles umkopieren.
Was gibts denn noch in der Trickkiste? Eine Liste! Die ist variabel in der Anzahl Einträge, ich kann die Einträge relativ einfach umsortieren, klingt perfekt. Aber in einer Liste speicher ich keine Records, sondern Objekte. Was ist der unterschied? Nun, praktisch gesprochen ist ein Objekt fast das gleiche wie ein Record, ich kann nur noch ein bißchen mehr damit machen:
Delphi-Quellcode:
type
TEintrag = class(TObject)
Name: String;
Nummer: String;
end;
TTelefonbuch = TObjectList;
var
Telefonbuch: TTelefonbuch;
begin
Telefonbuch := TTelefonbuch.Create(True);
...
(Exkurs TObjectList: Es gibt auch eine TList. Die hier verwendete TObjectList hat den Vorteil, dass man sich um das Aufräumen des Speichers nicht kümmern muss. Man sollte also immer die TObjectList anstatt der TList benutzen. Hierfür muss man in die oberste "uses"-Liste die
Unit "contnrs" aufnehmen.)
So, nu sind wir mit unseren Überlegungen doch schon ein ganzes Stück vorran gekommen. Den Rest jetzt noch eben fix selber zu machen, dürfte trivial sein, nicht wahr? Gerade wenn ihr in einer Gruppe zusammen arbeitet, dann kann man doch mal zusammen sowas wie ein Brainstorming machen und die Ideen zusammentragen.
So, und wenn dann noch Implementierungsfragen sind ("hm, ich hab hier eine Datenstruktur, die ich in einer TObjectList abspeicher. Wie kann ich die möglichst einfach auf Festplatte speichern und wieder einlesen"), dann kann man immer noch im Forum fragen und dann kann man die (wahrscheinlich zahlreichen) Antworten auch wirklich verstehen.
Sorry. Musste mal raus.
Gruß,
SirTwist