Mehrfachbehandlung von Events

[Delbor]

Hi zusammen

Hintergrund ist: Ich habe mehrere Frames, die miteinander über Events kommunizieren:

1. Ein ToolboxFrame enthält diverse Buttons zum kopieren, einfügen, löschen etc.
2. Mehrere Frames mit jeweils einem Synedit

Erstmal bin ich davon ausgegangen, dass ein abgefeuerter Event von verschiedenen Empfängern gleichzeitig abgefangen werden können. Zum Beispiel feuert der ToolboxFrame einen Event, um der Anwendung mitzuteilen, dass ein Button geklickt wurde. Ein Syneditframe regiert darauf und kopiert Text des Syneedits; gleichzeitig reagiert die Mainform, indem sie diie Darstellung der Sidebar anpasst (zum Bleistift den Inhalt der Zwischenablage anzeigt).
Ausgehend von dieser Annahme war ich der Meinung, dass verschiedene, auch vedeckte(weil auf verschiedenen Tabsheets), SyneditFrames auf diesen Event aus dem Toolboxframe reagieren würden. Das wäre sehr problematisch gewesen. Zum Glück haben mich dieser Thread und eigene Tests davon überzeugt, dass dem anders ist - der Test hat ergeben, dass nur gerade der Frame auf dem ActiveTabsheet auf das Event reagiert, auch wenn der Eventhandler mehrfach vorhanden ist.
Soweit, so gut, es funktioniert so, wie ich will - oder eben doch nicht ganz so gut, da ich im Moment nicht wirklich nachvollziehen kann, weshalb dies so ist.Hier mal einige meiner beteiligten Events:

Delphi-Quellcode:

procedure TToolBoxWebFrame.TLB_CopyClick(Sender: TObject);
  var Event: String;
begin
  if Assigned(FCopyOnClipBoard) then begin   //procedure DoCopyOnClipBoard(Event: String);
    Event := 'TLB_CopyClick';
    FCopyOnClipBoard(Event);
    TLB_Einfuegen.Enabled := True;
    TLB_Ausschneiden.Enabled := True;
    TLB_Copy.Enabled:= False;
  end;
end;

Obiger Event könnte ein simpler TNotifyevent sein, zur Kontrolle wollte ich aber einen Parameter mitgeben, der mir die Quelle im Synedit ausgibt, da ich in Eventprogrammmierung noch nicht wirklich sattelfest bin..
Der Eventhandler im Syneditframe:

Delphi-Quellcode:

procedure THTMLFrame.DoCopyOnClipBoard(const Event: String);
begin
   if SynEdit1.SelText.Length > 0  then begin
       SynEdit1.CopyToClipboard;
   end;
   SynEdit1.Lines.Add(Event);
end;

Ausserdem:

Delphi-Quellcode:

procedure THTMLFrame.SynEdit1MouseUp(Sender: TObject; Button: TMouseButton;
  Shift: TShiftState; X, Y: Integer);
begin
  if Synedit1.SelText <> '' then begin
    if assigned(FOnSelectText) then     
      FOnSelectText(Self);              
  end;
end;

und der Eventhandler:

Delphi-Quellcode:

procedure TToolBoxWebFrame.DoOnSelectText(Sender: TObject);
begin
Self.TLB_Copy.Enabled := True;
Self.TLB_Ausschneiden.Enabled := True;
end;

Und natürlich, um es nicht zu vergessen:

Delphi-Quellcode:

{***************************************************************************}
procedure TDelborWebServerMain.FormCreate(Sender: TObject);
  var Event: String;
begin
  SideBarWebFrame1.FileTreeFrame1.OnFileFound := DoOnFileFound;
  ToolBoxWebFrame1.OnPCtrlActivePage :=  DoOnPCtrlActivePage;
  SideBarWebFrame1.FileTreeFrame1.OnPathlist := DoOnPathList;

  ManageEvents;
end;

procedure TDelborWebServerMain.ManageEvents;
begin
  ToolBoxWebFrame1.OnCutOnClipBoard :=  SynEditFrame1.DoCutOnClipBoard;
  ToolBoxWebFrame1.OnCopyOnClipBoard :=  SynEditFrame1.DoCopyOnClipBoard;
  ToolBoxWebFrame1.OnPasteFromClipBoard := SynEditFrame1.DoPasteFromClipBoard;
  ToolBoxWebFrame1.OnOnSafe := SynEditFrame1.DoOnSafeSynedit;
  ToolBoxWebFrame1.OnOnOpen := SynEditFrame1.DoOnOpenSynedit;
  ToolBoxWebFrame1.OnOnNew := SynEditFrame1.DoOnNewSynedit;
  SynEditFrame1.OnSelectText := ToolBoxWebFrame1.DoOnSelectText;
end;

Im Moment nachvollziehbar ist: das Frame auf dem ActiveTabsheet ist wegen seines Parenmts Enabled und kann deshalb das Event empfangen; die Edits auf den andern Tabsheets sind nicht enabled und deren Eventhandler desshalb nicht assigned. Soweit so gut?

Nun kommt aber die Sache mit der Liste aus dem verlinkten Thread ins Spiel:

Zitat:

Du brauchst eine "Liste" von solchen Zeigern

TList<TBarcodeEvent>

Und da kann man via Add was hinzufügen und per Remove wieder entfernen.

Ok, die Liste gehört dahin, wo gefeuert wird
Hier die Eventtypen, die in meinem ToolbarFrame definiert sind (wie schon gesagt: alle könnten auch TNotifyEvent sein):

Delphi-Quellcode:

type
  TCutOnClipBoard = procedure(const Event: string)of object;
  TCopyOnClipBoard = procedure(const Event: string) of object;
  TPasteFromClipBoard  = procedure(const Event: string) of object;
  TOnSafe = procedure(const Event: string) of object;
  TOnOpen = procedure(const Event: string) of object;
  TOnNew  = procedure(const Event: string) of object;

Wenn ich das mit der Liste richtig verstanden habe, müsste eine solche nun für jeden Typen, der von mehreren Zielen/Eventhandlern empfangen werden soll, eine solche Liste anlegen.
Und da ist nun mein gordischer Knoten: In der Liste sind die Eventtypen mehrfach aufgelistet, aber diese Typen kennen ja ihr Ziel nicht??
Oder hab ich jetzt die Antwort gefunden: ein abgefeuertes Event kann genau von einem Eventhandler behandelt werden und muss deshalb per Liste mehrmals abgefeuert werden?

Gruss
Delbor

[jaenicke]

Ja, genau. Das nennt sich Multicastevent. Ich habe dafür eine von TList<T> abgeleitete generische Klasse gebaut, die die registrierten Eventhandler dann alle auslöst.

Ich schreibe auf der Autobahn im Auto, ein Beispiel folgt bei Bedarf später...

[himitsu]

Als Fahrer?

Aber im Notfall gibt es hier und da auch schon mehrere Beispiele zum finden. (bin mir fast sicher, daß es das schon mehrmals in der DP gibt, wenn man nach dem Begriff sucht)


@Captnemo: Er fährt bestimmt ein Googleselbstfahrauto.

[Captnemo]

Zitat von jaenicke:

Ich schreibe auf der Autobahn im Auto, ein Beispiel folgt bei Bedarf später...

Ich hoffe mal du fährst nicht selber, denn so wichtig kann keine Antwort sein, dass man das Risiko eingehen sollte.

[Rollo62]

Schau doch mal bei Spring4D nach ...
Da gibt es soetwas unter anderem.

Rollo

[Dejan Vu]

Zitat von Delbor:

Ok, die Liste gehört dahin, wo gefeuert wird

Wieso? Dann muss ja in Zukunft jede Klasse, die Multicast unterstützen soll, deine Logik nochmal implementieren. Schreib Dir doch lieber einen einzigen Multicasteventcontroller.
Derjenige, der etwas (ein Event) mitzuteilen hat, meldet sich und den Eventtyp beim Controller an.
Diejenigen, die benachrichtigt werden wollen, melden sich und den Eventtyp, über den sie benachrichtigt werden wollen, ebenfalls dort an. So hast Du eine lose Bindung und eine einzige Klasse, die alle Events verwaltet.

[jaenicke]

Zitat von himitsu:

Als Fahrer?

Nein, ich habe nicht einmal einen Führerschein.

Ich habe einfach das nicht als Eventcontroller implementiert, sondern lieber die Liste entsprechend. Sprich:

Delphi-Quellcode:

public
  property OnTest: TMulticastEvent<T> read FOnTest;

...

  Example.OnTest.Add(procedure(const ATest: string)
    begin
      ...
    end);

[Stevie]

Zitat von Dejan Vu:

Zitat von Delbor:

Ok, die Liste gehört dahin, wo gefeuert wird

Wieso? Dann muss ja in Zukunft jede Klasse, die Multicast unterstützen soll, deine Logik nochmal implementieren. Schreib Dir doch lieber einen einzigen Multicasteventcontroller.
Derjenige, der etwas (ein Event) mitzuteilen hat, meldet sich und den Eventtyp beim Controller an.
Diejenigen, die benachrichtigt werden wollen, melden sich und den Eventtyp, über den sie benachrichtigt werden wollen, ebenfalls dort an. So hast Du eine lose Bindung und eine einzige Klasse, die alle Events verwaltet.

Wo ist das Smiley mit Kreuz, Knoblauch und Pflock, wenn man es braucht?
Das klingt mir aber sehr nach einem Singleton - ne tolle lose Binding
Und EDA braucht man für diesen Anwendungsfall eher nicht.

[Dejan Vu]

Wie kommst Du auf Singleton?

[Stevie]

Zitat von Dejan Vu:

Wie kommst Du auf Singleton?

Hab ich einfach mal so angenommen (immerhin macht es System.Messaging so vor) - aber ok, kein Singleton. Und wie wissen nun Producer und Consumer von diesem "einen einzigen Multicasteventcontroller"?