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.")