Zitat:
Das könnte man entkoppeln, was etwas schöner wäre. Aber auch das ist noch OK. Kann man so machen.
Wie meinst Du "entkoppeln"?
Eigentlich muss eine Klasse, die Spieler oder Mannschaften verwaltet, gar nicht wissen, dass diese in
XML-dateien gespeichert werden. Das kann in ne separate Klasse. Dadurch kannst du das Dateiformat leicht ändern, die Daten auch mal in ne Datenbank schreiben u.ä. ==> Die Datenpersistenz ist von der Datenrepräsentation entkoppelt. Lose Lopplungen machen ein Programm also flexibler, deshalb versucht man meist eine möglichst lose Kopplung zu erreichen.
Zitat:
Zitat:
Was aber, wenn die oberen darauf reagieren müssen, wenn auf den unteren Schichten was passiert? Dafür gibt es Indirektionsmechanismen. Also Events oder beispielsweise das Observer-Pattern.
Das klingt strukturell sehr sinnvoll. Ich werde das mal über ein Event ankoppeln. Der Grundsatz, dass alle sichbaren Komponenten ungültig und bei Gelegenheit neu gezeichnet werden, bleibt ja aber dadurch gleich...
Jein. Das sollte unabhängig vom Neuzeichnen sein. Die Komponenten zeichnen sich neu, wenn das nötig ist. Punkt. Zweitens kann es sein, dass sich die Darzustellenden Daten geändert haben. Das bemerkst du über n Event, liest die neuen Daten ein und rufst dann Invalidate auf. Das Einlesen der neuen daten, erstellen und Löschen von Objekten, etc. geschrieht aber in diesem Event. In OnPaint hat das nix verloren. Das ist das Problem. In OnPaint gehört nur Zeichencode. Nix anderes.
Zitat:
Daher suche ich im
DC.Destroy alle Zeiger auf diese und setze sie auf nil. Das funktioniert, sofern ich weiß, wo diese Verweise vokommen können.
Zwischen "funktioniert" und "ist gut" ist aber noch ein Unterschied...
Zitat:
Zitat:
Jein. Du löst das Problem nicht, du umgehst es.
Hmm, wie ginge es besser?
Siehe oben. In OnPaint gehört nur Zeichencode. Wenn du das beherzigst, hast du die Probleme nicht.
mfg
Christian