Telefonbuch-Schuleprojekt und wir sind hilflos

[maker]

Ich habe hier gerade Delphie 7

mfg. maker

[Die Muhkuh]

Personal?

[maker]

Oh ja sry Personal hatt ich ganz vergessen
mfg. maker

[DeddyH]

Könnt Ihr das Thema DB mal ad acta legen? Ich finde, das ist hier vollkommen überdimensioniert (und zwar in allen Belangen).

[edit] Mein Ottografie ( ) ist nach einigen Bierchen nicht mehr die Sicherste [/edit]

[Die Muhkuh]

Dann hast Du Pech gehabt. Die Personal bietet keine Unterstützung für Datenbanken.

Schau Dir mal Turbo Delphi Explorer an, die ist kostenlos und bietet auch Unterstützung für Datenbanken an. Jedoch kannst Du keine Drittkomponenten installieren, aber Du hast schon über 200 dabei, die reichen Dicke.

www.turboexplorer.com

Jedoch solltest Du, wie DeddyH schon erwähnte, nicht gleich auf Datenbanken aufsetzen, typisierte Dateien bieten sich hier "genau so gut" an.

[edit] Detlef, sauf nicht so viel [/edit]

[maker]

Aber wieso ad acta? Das Beispiel was ich gefunden habe ist ja nunmal mit DB und verständlicher bekomm ich es so schnell sicher nicht erklärt.
Zwischendurch übrigens nochma danke für die liebe und schnelle Hilfe und das zu so unchristlicher zeit. Ja ich weiss DB`s sind net allzu einfach aber..nunja wie soll ich sagen. Es ist ne gute Lösung wie ich finde. Also na gut ich überlegt mir das ganze ma und schlaf drüber ma schaun was ich da morgen draus machen kann.
Jendenfalls ganz großes dankeschön an euch alle

mfg. maker

[DeddyH]

Ob Dein Lehrer damit einverstanden ist, wenn Ihr gleich mit Datenbanken loslegt, wage ich zu bezweifeln.

[omata]

Ein Vorschlag...

[Dani]

Zitat von Die Muhkuh:

Um es gleich vorweg zu sagen: Eure Hausaufgaben wird hier keiner schon irgend jemand aus reiner Langeweile machen.

[SirTwist]

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