Adressbuch Konzept

Dude566 · Verfasst: Sa 19.06.10 14:13

Hallo,

ich bin momentan dabei ein kleines Adressbuchprogramm zu entwickeln, nur zu Übungszwecken.

Als Vorlage, wie es irgendwann einmal eingesetzt werden könnte, habe ich mir www.chip.de/download...h-2009_21744584.html als Beispiel genommen.

Allerdings ohne Datenbanken, ich möchte die Daten in eine typisierte Datei mit eigenem Datentyp (record) speichern.

In der oben angegebenen Software übernimmt er schon beim Eintragen von Daten alles in die rechte Tabelle und speichert sie wohl auch, wie kann ich das am besten realisieren?
Ich hatte zunächst versucht bei jedem Exit Ereigniss eines Edits meine Speicherprozedur aufzurufen, doch da müsste dann ja noch eine Prüfung rein ob ich einen Datensatz hinzufügen möchte oder einen vorhanden bearbeite und dann die Änderungen Speichern möchte. In der Beispielsoftware sind aber nur 3 Buttons für die Kontrolle der Datensätze und es klappt dort prima.

Also wie soll ich mein Programm aufbauen, habt ihr irgendwelche Ideen oder Entwürfe?

Mit freundlichen Grüßen,
Dude566

_________________
Es gibt 10 Gruppen von Menschen: diejenigen, die das Binärsystem verstehen, und die anderen.

ALF · Verfasst: Sa 19.06.10 14:49

Fang doch vom Anfang an! Also du hast noch keine Adressen im Buch!
Editcomponenten, je nach dem wie Du es aufschlüsselst.
Name, Vorname, Komplette Adresse(oder einzelne Edits für Ort Strasse Hausnr. usw.) Telf, oder was du noch willst.
Im changeereignis ne Variable setzen das Du was gemacht hast. Dadurch wird der SpeichernButton z.B. aktiviert.
Befor Du jetzt irgendwas laden tust oder beendest, kommt der Hinweiss das Daten geändert wurden! Speichern ja/nein.
Beim Laden von Daten das changeereignis deaktivieren, danach wieder aktivieren, schon geht alles wieder von vorn los! Währe meine Idee!
Die Feinheiten, wie gross Dein Adressbuch ist, wieviele Einträge es hat, oder ob ein Eintrag schon vorhanden ist ergeben sich von selbst :wink:

Das automatische Speichern hat aber auch Nachteile!
Überprüfen ob die Daten schon vorhanden sind z.B.
Nachfragen ob überschrieben werden soll usw.
Gruss Alf

_________________
Wenn jeder alles kann oder wüsste und keiner hätt' ne Frage mehr, omg, währe dieses Forum leer!

Dude566 · Verfasst: Sa 19.06.10 15:23

ALF hat folgendes geschrieben :

Die Feinheiten, wie gross Dein Adressbuch ist, wieviele Einträge es hat, oder ob ein Eintrag schon vorhanden ist ergeben sich von selbst :wink:

Das automatische Speichern hat aber auch Nachteile!
Überprüfen ob die Daten schon vorhanden sind z.B.
Nachfragen ob überschrieben werden soll usw.
Gruss Alf

Genau da muss ich mir noch was überlegen, aber danke für deinen Vorschlag mit der Variable.
Also sollte ich diese Daten die eingegeben werden erst in ein Array von meinem Datentyp speichern und erst auf Anforderung oder beim Beenden des Programms diese mit den vorhandenen Daten in der Datei überprüfen und dann erst speichern.

Edit: Habe mal eine Prozedur zum Speichern der eingegeben Daten in mein Array geschrieben, ich habe echt keine Ahnung warum ich da eine Zugriffsverletzung bekomme.

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:
19:
20:
21:
22:
23:
24:
25:
26:
27:
28:
29:
30:

public
    MyContact : array of TContactPerson;
    procedure SetData();

// Add a contact
procedure TmainForm.SetData();
var
   l : integer;
begin
  l := Length(MyContact);
  SetLength(MyContact, l+1);
  MyContact[l-1].FName := edtName.Text;
  MyContact[l-1].FFirstName := edtFirstname.Text;
  MyContact[l-1].FStreet := edtStreet.Text;
  try
    MyContact[l-1].FStreetNr := StrToInt(edtHouseNr.Text);
    MyContact[l-1].FPostal := StrToInt(edtPostalCode.Text);
  finally
  end;
  MyContact[l-1].FPlace := edtPlace.Text;
  MyContact[l-1].FCountry := edtCountry.Text;
  MyContact[l-1].FPhone := edtPhone.Text;
  MyContact[l-1].FMobile := edtMobile.Text;
  MyContact[l-1].FTelefax := edtTelefax.Text;
  MyContact[l-1].FDefinition := edtDefinition.Text;
  MyContact[l-1].FEMail := edtEMail.Text;
  MyContact[l-1].FWebsite := edtWebsite.Text;
  MyContact[l-1].FBirthday := StrToDate(edtBirthday.Text);
  MyContact[l-1].FGroup := cmBoxGroup.Text;
end;

TContactPerson:

markieren

Delphi-Quelltext

1:
2:
3:
4:
5:
6:
7:
8:
9:
10:
11:
12:
13:
14:
15:
16:
17:
18:

type
  TContactPerson = record
    FName : string[64];
    FFirstName : string[64];
    FStreet : string[64];
    FStreetNr : integer;
    FPostal : integer;
    FPlace : string[64];
    FCountry : string[64];
    FPhone : string[64];
    FMobile : string[64];
    FTelefax : string[64];
    FDefinition : string[255];
    FEMail : string[64];
    FWebsite: string[64];
    FBirthday : TDate;
    FGroup : string[20];
  end;

_________________
Es gibt 10 Gruppen von Menschen: diejenigen, die das Binärsystem verstehen, und die anderen.

ALF · Verfasst: Sa 19.06.10 16:21

Na ja, bischen doppeltgemoppelt ist es schon! Du kannst die Daten vom Edit ja gleich mit übernehmen im Record. Entweder im exit(was nicht immer sicher ist) oder ebenfalls im onchange vom Edit. Also keine extrprocedure dafür!
Alles andere, testen obschon vorhanden vor dem Speichern ist klar. Dabei natürlich auch auf die Auflösung denken, was schon vorhanden ist Telefon, Name, z.B.
Vorname nur in verbindung des Nachnamen und umgekehrt usw.

Wird ne komplizierte Aufgabe, die ganzen vergleiche usw ohne DB.

Gruss Alf

_________________
Wenn jeder alles kann oder wüsste und keiner hätt' ne Frage mehr, omg, währe dieses Forum leer!

Gerd Kayser · Verfasst: Sa 19.06.10 18:56

Dude566 hat folgendes geschrieben :

markieren

Delphi-Quelltext

1:	FPostal : integer;

Ein kleiner Tipp: Für die Postleitzahl sollte man einen String mit 10 Zeichen Länge vorsehen.
de.wikipedia.org/wiki/Postleitzahl

jaenicke · Verfasst: Sa 19.06.10 19:04

Große Nachteile einer solchen typisierten Datei sind, dass einerseits viel Speicherplatz verschwendet wird und andererseits dennoch nicht unbedingt genug Platz zur Verfügung steht.

Das heißt jetzt nicht, dass ich unbedingt eine Datenbank favorisiere. Ich selbst habe da auch durchaus eigene optimierte Lösungen eingesetzt.
Sinnvoll ist aber auf jeden Fall eine dynamische Datenstruktur um nicht an feste Größen für die Daten gebunden zu sein.

Zudem kannst du so dann auch sehr einfach zum Beispiel Bilder oder ähnliches mit in die Datei speichern.

Dude566 · Verfasst: Sa 19.06.10 19:46

jaenicke hat folgendes geschrieben :

Sinnvoll ist aber auf jeden Fall eine dynamische Datenstruktur um nicht an feste Größen für die Daten gebunden zu sein.
Zudem kannst du so dann auch sehr einfach zum Beispiel Bilder oder ähnliches mit in die Datei speichern.

Du sprichst jetzt aber nicht von einer typisierten Datei oder? :gruebel:

Ich verstehe nicht ganz was du meinst, ich habe doch eine dynamische Datenstruktur, mit jedem neuen Datensatz wird halt mehr Speicherplatz gebraucht.

_________________
Es gibt 10 Gruppen von Menschen: diejenigen, die das Binärsystem verstehen, und die anderen.

jaenicke · Verfasst: Sa 19.06.10 20:28

Ich meine, dass du pro Datensatz 1 KiB benutzt obwohl da vielleicht nur 50 Byte benutzt werden. Das ist bei den heutigen Festplatten zwar kein Problem, aber dennoch unnötig.

Zusätzlich kannst du aber eben keine Zusatzdaten wie Fotos oder so mit einbinden. Denn die Dateistruktur ist ja so vollkommen fest.

Sicher, für deinen Zweck mag es ausreichen, aber typisierte Dateien verwende ich selbst eher ungern. Auch weil man da keinen Dateiheader benutzen kann (jedenfalls nicht direkt). Über den Dateiheader läuft bei mir zum Beispiel die versionsabhängige Behandlung der Datei um auch ältere Dateien mit neueren Versionen meiner Programme noch verwenden zu können.

Ehemaliges Mitglied Erhaltene Danke: 1

jaenicke hat folgendes geschrieben :

Auch weil man da keinen Dateiheader benutzen kann (jedenfalls nicht direkt).

Ich weiß zwar nicht, was du mit direkt oder indirekt meinst, aber wo ist das Problem bei einer typisierten Dtei einen Record voranzustellen, der die Version und weitere Informationen enthält?

Ich weiß nicht, ob das schon vorgeschlagen wurde, aber es würde sich eventuell lohnen sich mal XML-Dateien anzugucken.

	Mitgliederliste
	Gruppen
	Das Team
	Richtlinien
	Synonyme