Formular neu zeichnen erzwingen

[guidok]

Siehe den Beitrag #7

Gruß,

Guido

[alzaimar]

Zitat:

Zitat von Optiplex

Hast du mal ein Beispiel in Delphi für mich oder waren das nur Schlagworte die du drauf hast? :zwinker:

1.Ja und 2.nein. :zwinker:

[Optiplex]

Hallo

@Alzaimar
mit so oder einer ähnlichen Antwort muss man bei einer kleinen Provokation rechnen. Was muss ich tun damit du mir verzeihst? und mir dein Beispiel doch noch gibst?
@Guido
danke für den link, ich sehen schon etwas klarer, wobei ich immer noch Umsetzungsprobleme habe. :oops:

@ Alle
Ich habe verstanden, dass ich eigentlich nicht anderes habe als ein Objekt, in diesem Objekt verwalte ich eine Zeigerliste die auf eine Methode zeigen.

1 kann diese Methode in einer Komponente sein z.B. Componente.update oder muss diese sich im Programm direkt befinden
2 wie melde ich diese Methode in meine Liste an bzw. ab
3.wie wird mein Überwachungsobjekt benachrichtigt, dass sie etwas tun muss.

ich habe z.B. zwei Objekte TPerson und TPersonList und zwei Komponenten eine TPersonEdit und TPersonScrollbox jetzt wird eine Person geändert z.B. Namen innerhalb der Objekte klappt das, nur der Bildschirm wird nicht aktualisiert. Wie kann ich das mit einem Observer lösen?

wie ich schon sagte, blicke ich mit dieser Observergeschichte noch nicht ganz durch, scheint aber ganz interessant zu sein, weil sich scheinbar damit eine ganze reihe von Problemen lösen lassen. Ich hoffe ihr helft mir weiter.

Gruß Dieter

[guidok]

1. Kann diese Methode in einer Komponente sein z.B. Componente.update oder muss diese sich im Programm direkt befinden?

Verstehe die Frage nicht ganz, aber die Methode muss eine Ereignisbehandlungsprozedur sein.

2. Wie melde ich diese Methode in meine Liste an bzw. ab?

Das Subject hat dafür die beiden Methoden "MeldeAn" und "MeldeAb" (Aus dem Beispiel entnommen).

3. Wie wird mein Überwachungsobjekt benachrichtigt, dass es etwas tun muss?

Das Subject benachrichtigt die angemeldeten Beobachter (d.h. es ruft die angemeldeten Ereignisbehandlungen auf). Das Subject selbst sollte natürlich das Objekt sein, in dem die sich ändernden Daten gehalten werden und dementsprechend "merken", wenn sich daran was ändert.

Beispielsweise könnte das Subject eine TCollection enthalten, die hat dann auch ein Ereignis "Changed", in dem du entsprechend reagieren kannst. "Changed" wird immer aufgerufen, wenn sich an einem TCollectionItem etwas ändert (TCollection speichert TCollectionItems).

Zitat:

Zitat von Optiplex

ich habe z.B. zwei Objekte TPerson und TPersonList und zwei Komponenten eine TPersonEdit und TPersonScrollbox jetzt wird eine Person geändert z.B. Namen innerhalb der Objekte klappt das, nur der Bildschirm wird nicht aktualisiert. Wie kann ich das mit einem Observer lösen?

Ich nehme an TPersonList enthält eine gewisse Anzahl von TPerson.

Das heisst dann, dass TPersonList das Subject ist und TPersonEdit und TPersonScrollbox sind Beobachter. Ändert sich jetzt etwas an der Personenliste, dann werden die Beobachter benachrichtigt und können sich aktualisieren.

[DerDan]

Hallo Opti,

Hast du schon mal versucht herauszubekommen, warum

Delphi-Quellcode:

Form1.Caption := 'Hallo Delphi';

funktioniert, ohne das man da explizit sagen muss, das sich der Titel neu zeichnen muss.

Versuch doch einfach mal herauszubekommen wie das geht und mach das bei deinen Komponenten ähnlich.

Nur mal so als Hinweis: Wenn in der Frage das Wort "erzwingen" drin steht, dann hast du schon einen Denkfehler.

mfg

DerDan

[alzaimar]

Zitat:

Zitat von Optiplex

@Alzaimar
mit so oder einer ähnlichen Antwort muss man bei einer kleinen Provokation rechnen. Was muss ich tun damit du mir verzeihst? und mir dein Beispiel doch noch gibst?

Spaßversteher sein :mrgreen: :

[guidok]

Zitat:

Zitat von DerDan

Hallo Opti,

Hast du schon mal versucht herauszubekommen, warum

Delphi-Quellcode:

Form1.Caption := 'Hallo Delphi';

funktioniert, ohne das man da explizit sagen muss, das sich der Titel neu zeichnen muss.

Naja, dass ist schon ein wenig anders. Caption ist einfach eine Property und hat eine entsprechende Settermethode, in der z.B. auch das Zeichnen des Formulars aufgerufen werden kann.

Er möchte ja mehrere voneinander unabhängige Objekte davon informieren, dass eine Änderung eingetreten ist, die evtl. eine Aktualisierung erfordern. Grundsätzlich folgt er damit ja dem Prinzip Daten und GUI zu trennen und ist auf dem richtigen Weg.

[Optiplex]

Hallo zusammen

@Guido,
die Schatten lichten sich, scheinbar liegen meine Verständnisprobleme mehr bei den neuen von mir nicht bekannten Bezeichnungen. Ich habe es geschafft, mit der Unit aus deinem Link, dass die Benachrichtigung Objekt zur Komponente funktioniert. Erstmal bin ich darüber sehr Happy.

Zitat:

Beispielsweise könnte das Subject eine TCollection enthalten, die hat dann auch ein Ereignis "Changed", in dem
du entsprechend reagieren kannst. "Changed" wird immer aufgerufen, wenn sich an einem TCollectionItem etwas
ändert (TCollection speichert TCollectionItems).

Das habe ich nicht ganz verstanden, meinst du ich sollte den Array in TSubjekt in einen TCollection umwandeln? Ich kenne die verschiedenen Listen nicht genau, (weis nicht wann ich welche Liste ich nehmen soll, da ich deren Vor- und Nachteile nicht genau kenne)da müsstet du mir nochmals helfen. Kannst du TSubjekt auf TCollection umschreiben?


@Alzaimar,
wenn du ein Spaßversteher bist dann liegen wir beide auf derselben Wellenlänge. :zwinker:
Wow deine Unit sieht ja richtig Prof aus. Allerdings hätte ich mir gewünscht, dass ein paar Kommentare drinn sind, um sie besser zu verstehen. Ich habe zum Beispiel nicht verstanden warum du ein Hilfsobjekt zu TSubject machst. In TSubject arbeitest du schon mit einer TObjectList was ich sehr gut finde da sie leichter zu händeln ist als ein Array. In der Unit SampleClass.pas machst du noch ein Objekt TObserverableObject für was wird dieses benötigt? wenn ich das richtig sehe könnte ich doch auch gleich von TSubject ableiten oder? Was sind den die Vorteile gegenüber der Unit von Guido die ja recht einfach gehalten ist?

So das sind eigentlich genug Fragen für den frühern Morgen

Gruß und einen schönen Tag
Dieter

[alzaimar]

Zitat:

Zitat von Optiplex

Allerdings hätte ich mir gewünscht, dass ein paar Kommentare drinn sind, um sie besser zu verstehen.

Ich sitze in der Türkei bei 35°C am Meer und soll auch noch Kommentare schreiben? :zwinker:

Die Klasse TSubject definiert eine Struktur, die eine Nachricht 'Changed' an andere (per Subscribe angemeldete) Objekte zu verteilen.
Die Klasse TCallbackHelper dient nur dazu, eine Methodenzeiger in einer Liste zu verwalten. Ich hätte auch ein 'Array Of TObserverNotification' verwenden können, dann hätte ich mir diese Hilfsklasse sparen können. Aber ich mag dynamische Arrays (hier) nicht.

Gut gut, die Unit 'Observer' hat uns also die Grundbausteine für das Pattern bereitgestellt. Wie gehen wir damit um?

Wir haben also unsere Daten-Klassen, die wir um jeweils ein 'Subject' erweitern und dieses Subjekt (Man könnte es auch 'Änderungsnachricht-Verteil-O-Mat' nennen, aber 'Subject' ist irgendwie kürzer. Gut, schwerer zu verstehen, aber kompakt. Geradlinig. Straff. Drahtig. Sch..Schön. Darauf kommt es an. :freak: Äh.. *vomthemaabschweifweilbikinismitinhaltflanieren* Wo war ich? ach ja.

Also, wir erweitern unsere Datenklasse um so ein 'Subject', damit andere Programmteile, die von den Änderungen an dieser Datenklasse informiert werden müssen, dort anmelden können. Dazu implementieren sie so eine Methode vom Typ 'TObserverNotification' und melden sich eben dort an.

Ich habe in der Klasse 'TObserverableObject' die Grundfunktionalität bereitgestellt, die eine Datenklasse, die Änderungen weiterverbreiten kann, so benötigt. Wenn Du deine Datenklassen von diesem Objekt ableitest, haben deine Klassen bereits alles, was ein Observerpattern so braucht. Du musst es nur noch anwenden, d.h. die Visualisierungsklassen bzw. Formulare per Subscribe anmelden und fertig.

Jeder 'Setter' einer Eigenschaft muss zum Schluss nur die 'Changed'-Methode aufrufen (wenn die Property geändert wurde). Mit 'BeginUpdate' kann man die Benachrichtigung puffern, also mehrere Änderungen vornehmen, ohne das jedesmal alle Subscriber benachrichtigt werden. Das würde ja nerven. Wenn ich also viele Eigenschaften eines Objektes ändern will, rufe ich 'BeginUpdate' auf, ändere wie ein Weltmeister und schließe die Änderungen mit 'EndUpdate' ab.

Ich kann das auch sein lassen, dann werden aber bei *jeder* Änderung die Subscriber benachrichtigt.

Die Idee von Guido ist natürlich für einige Objekte vielleicht mit weniger Aufwand zu implementieren, aber wenn in deiner Anwendungen viele Objekte durch die Gegend fliegen, die alle irgendwie dargestellt werden, hättest Du bald Probleme mit den ganzen Messages.
Ich mach das ab und an genauso, wenn ich nur ein oder zwei Klassen habe, die visualisiert werden müssen, aber wenn es mehr werden :kotz: ...

Das Observer-Pattern bietet dir hier eine orthogonale (also gleichförmige), robuste und einfache Möglichkeit an, dieses Chaos zu vermeiden. Bei der komplexen Softwareentwicklung kommt es imho in erster Linie darauf an, robust, einfach, verständlich und damit wartbar und erweiterbar zu programmieren und nicht kurz und knapp (a.k.a 'Quick and Dirty').

[Optiplex]

Hallo Alzaimar,

Das nenn ich mal eine Beschreibung, warum nicht gleich so! :zwinker: Ich wusste, dass du dir etwas bei diesem TObserverableObject gedacht hast, konnte nur nicht erkennen was. Das kann man bestimmt manchmal recht gut gebrauchen. Wenn ich also meine Klasse von TSubjekt ableite habe ich die selbe Funktion wie bei Guido's Unit und für zusätzliches ein- und ausschalten der sofortigen Chances kann ich dann von TObserverableObject ableiten, so habe ich beide Möglichkeiten (Nicht schlecht H. Specht).

Also nochmals danke für die Unit, werde sie am Wochenende mal testen und sagt dir dann noch Bescheid ob es geklappt hat. Wobei ich Guidos Unit nicht schlecht finde die funktioniert bis jetzt tadellos.

Ach ja bevor ich es vergesse, könntest du mir bitte 'bikinismitinhalt' an deine nächste Antwort mit dranhängen. Im voraus meine besten Dank dafür. :zwinker:

Gruß Dieter