OnEreignis einer Komponente --> mehrere Prozeduren aufrufen

[berens]

Hi!

Bei (Windows-)Messages wird ja jedem, der sich in die Kette (Message-Chain?) eingeklingt hat mitgeteilt, dass etwas passiert ist, z.B. ClipBoard geändert o.ä.

Wie kann ich denn machen dass, wenn eine Komponente z.B. OnChange auslöst, dies mehrere Komponenten mitbekommen (ich weiß vorher nicht wieviele; die werden zur Laufzeit dynamisch erstellt).



Stupides Beispiel: Ein TEdit löst beim Ändern das OnChange Ereignis aus. Nun sollen alle dynamisch erzeugten TLabels die gleiche Caption bekommen wie der Edit1.Text.


Hinweis: Mit einer TComponentList etc. möchte/kann ich hier nicht arbeiten, da alle meine verschiedenen Componenten dann von einer gemeinsamen Komponente abstammen müssten etc. Wie gesagt, beim ClipBoardChange klappt das ja auch.


Hoffe konnte mich klar ausdrücken, danke im Vorraus für Rückmeldungen.


PS: UTFS konnte ich leider nicht machen, da ich nicht wusste, wonach ich suchen soll.

[SirThornberry]

Du könntest vom TEdit ableiten und dort die Möglichkeit bieten mehrere OnChange-Methoden zu registrieren (oder mehrere TEdits).

[berens]

naja, das kann man wohl machen, wenn man genau weiß, wie viele Komponenten es später geben wird

Delphi-Quellcode:

TMyEdit = class(TEdit)
[...]
public
  property OnChange1: TNotifyEvent;
  property OnChange2: TNotifyEvent;
  property OnChangeN: TNotifyEvent;
[...]

Sobald aber dynamisch beliebig viele Komponenten erzeugt werden, ist das nicht mehr machbar.


Hintergrund:
Ich habe in meinem Programm eine Datenbankschnittstelle, welche die wichtigsten Daten der Datenbank vorhält (Entlastung der Datenbank durch Lesezugriffe). Diese Schnittstelle prüft dann alle X Sekunden/Minuten ob es (wichtige) Änderungen gab, wenn ja, sollen alle anderen Module benachrichtigt werden.

Da ich aber zur Programmierzeit nicht weiss, welche Module beim Kunden laufen (evtl. auch welche, die später erst Programmiert werden), möchte ich einfach nur bei dieser Datenbankschnittstelle meine "Rückrufnummer" (TNotifyEvent) zurücklassen, falls sich etwas ändert.

Wenn es Änderungen gibt, werden dann alle Komponenten der Reihe nach "zurückgerufen", also informiert, dass sich was geändert hat. In der jeweiligen Prozedur (die von der Schnittstelle aufgerufen wird) holt sich die Komponente dann die aktuellen Daten aus der Schnittstelle, die sie benötigt.


Meine letzte Idee wäre eine TListe zu machen, und der Datenbankschnittstelle sowas wie "RegisterEvent" und "UnregisterEvent" hinzuzufügen, mit dem sich die Module/Komponenten bei der Schnittstelle "anmelden" (Create) und später auch wieder "abmelden" (Free) können. Habe nur Angst, dass irgendwann (weshalb auch immer) die TList nicht aktuell ist und die TNotifyEvent Einträge in der TList veraltet sind, und ich nun einen Speicherbereich "ausführe", in dem ggf. Benutzerdaten sind. Stichwort: NoExecute.

Dachte nur, bei Delphi gibt es da schon sowas ähnliches, weil bei einem ClipBoardChange klappt das ja auch. ("Hey Zwischenablage, sag mir bescheid, wenn's was neues gibt!" - "Ok, geht klar.")

[himitsu]

dann erstellst du dir sozusagen eine MessageHandleClass,

diese wird bei OnChange des Edits eingetragen
und dann werden die Labels bei dieser Klasse registriert und z.B. in einer ObjectList gespeichert.

kommt jetzt ein OnChange an, dann geht diese Klasse ihre Liste durch und meldet das sozusagen an die registrierten Labels weiter.


wobei ich das Beispiel eh etwas eignartig finde, da man ja kein Label bei einem Edit in OnChange eintragen kann ... außerdem wüßte das Label dann eh nicht, was es machen soll.

[berens]

Ja, aber gibt es in Delphi schon eine fertige MessageHandleClass oder muss ich die tatsächlich komplett selbst programmieren?

Edit: Nein, das Label selbst wird nicht eingetragen. Das Label in diesem Beispiel wäre ein abgeleitetes TLabel, beispielsweise mit einer Prozedur procedure AktualisiereInhaltVonEdit(Sender: TObject); . Sobald das Edit sich ändert, ruft es von den TLabels und den anderen Komponenten z.B. AktualisiereInhaltVonEdit auf.

Ist ja auch nur ein Beispielt, geht ja mehr ums Prinzip. Eigentliche Verwendung ist die o.g. Datenbankschnittstelle.

[himitsu]

wirst du wohl selber machen müssen, abgesehn davon, daß es bei einem Label nicht ginge, denn (wie gesagt) wenn es sowas gäbe, dann wüßte diese Klasse dann nichts mit dem Label anzufangen ... so nach dem Motto "toll, ich hab eine Nachricht bekommen, aber was soll ich jetzt am Label ändern?"
also muß diese Klasse schon extra für das/dein Label erstellt wurden sein und somit wäre sie nicht mehr allgemeingültig und viele andere könnten mit dieser Klasse nichts anfangen.

man könnte höchstens soeine Klasse als "fertiges" erstellen, welches z.B. eine Ereignisprozedur besitzt, welche man z.B. in OnChange irgendeiner Klasse einträgt und wo dann bei den registrierten Klassen jeweile eine bestimmte Ereignis-Prozedur aufgerufen würde (via RTTI könnte man maximal und unter bestimmten umständen noch den Namen der Ereignisprozedur der registrierten Klassen variabel machen)


[add]
mach es doch so, wie es viele Andere auch machen :zwinker:

- wo erstellst du denn diese Labels? (laut OOP wohl in einer Klassenprozedur)
- genau in dieser Klasse hast du nun eine ObjectList mit den Labels, wo jedes erstelle Label eingetragen ist
- und in der selben klasse gibt es eine Callback-Prozedur, welche in das OnChange des Edits eingetragen wird
- ändert sich nun etwas im Edit, dann bekommt deine Klasse es mit
und kann z.B. entsprechend die ganzen Labels aktualisieren, denn deine Klasse weis ja was sie nun machen muß (bzw. du hast ihr "gesagt" was zu tun ist, wann eine Nachricht eintrifft)

[guidok]

Da gibt es doch auch ein Entwurfsmuster dazu:

--> Observer Pattern

Beispiel in Delphi

[berens]

Das war genau das, was ich in als Suchbegriff eintippen wollte, aber bis dahin nicht kannte: Observer-Pattern. Dies betrifft genau das, was ich brauche. Zudem spiegelt es meine o.g. Idee wieder.

DP-Suche: Observer Pattern
http://www.codeproject.com/KB/archit...erPattern.aspx
Thread zu dem Thema

Thema vorläufig erledigt, vielen Danke allen.