Ereigniss-Aufrufe (OnChange etc.) eines Forms protokollieren

[delphitrixer]

Hallo Zusammen

Ich möchte gerne auf meinem Form eine ListBox haben, die alle Events (OnChange, OnEnter, OnKeyPress etc.) aller
darauf befindlichen Komponenten chronologisch auflistet. Oft habe ich das Problem, dass bei vielen OnChange-Prozeduren
und Abhängigkeiten der einzelnen Komponenten die auf dem Form sind, nicht ganz überschaubar ist, welches Event
Delphi nun in welcher Reihenfolge abarbeitet.

Es wäre also praktisch, wenn man die Reihenfolge der aufgerufenen Ereignisse in der Liste angezeigt bekommt. Also so
eine Art Event-Viewer für das eigene Projekt.

Hat jemand einen praktischen und einfachen Vorschlag?

Danke

[MrKnogge]

Du fügst in jedem Event deiner Listbox einen Eintrag hinzu !?

[delphitrixer]

Danke MrKnogge, aaaaaaber...

Ich möchte natürlich nicht in jedem Event eingreifen müssen, sondern dies irgendwie "zentral"
lösen. Es muss doch sicherlich möglich sein, irgendwie alle Ereignisse die ausgelöst und auf-
gerufen werden, an einem Punkt abzuhandeln und zu protokollieren.

[MrKnogge]

Wenn einem Event aber keine Methode zugewiesen wurde, wird dieser auch nicht ausgelöst.

[SirThornberry]

ist es nicht. Denn dafür bräuchtest du ja für jedes Ereignis eine entsprechende Methode die genau dem Ereignis entspricht.
Denn schließlich ist das auftreten eines Ereignisses nichts anderes als ein Funktionsaufruf aus der Komponente heraus. Wenn es keine Funktion gibt die aufgerufen werden kann wird auch nix aufgerufen.

In der Komponente steht sinngemäß drin:
- Wenn eine Ereignis-methode zugeweisen wurde dann rufe diese mit parameter X und Y auf.

Und ist dort nix zugeweisen passiert diesbezüglich gar nix.

[delphitrixer]

natürlich möchte ich auch nur die ereigniss protokollieren, denen ich auch selber methoden
zugeordnet habe. trotzdem möchte ich aber nicht jeder methode hinterlegen müssen, dass diese
nun noch einen eintrag in einer liste machen soll mit dem hinweis, dass sie nun aufgerufen
wurde.

stellt auch vor, ihr habt ein form mit 200 bestehenden methoden und möchtet nun nachträglich
nur mal so aus sicht einer fehlersuche mal eben wissen in welcher reihenfolge nun welche
methode aufgerufen wird. ist natürlich nicht gerade "hübsch" nun allen methoden mal schnell
eine zeile code hinzuzufügen. besonders dann nicht, wenn es hinterher wieder raus soll.

löst den der auf aufruf einer methode, die einem ereigniss zugeordnet ist, nichts anderes eine
art message aus, die wiederum irgendwo abgefangen und protokolliert werden kann?

[MrKnogge]

Eine Alternative wäre es, Haltepunkte zu setzen.

[delphitrixer]

die unit hat knapp 23'000 zeilen. das mit den 200 methoden war nur ein beispiel. es sind
in diesem fall knapp 850 methoden enthalten. das wären durchaus viele haltepunkte die zu
setzen wären.

[Apollonius]

Es gäbe eine sehr eklige Variante, die ein Hooken von TObject.MethodAddress involvieren würde, sodass in Wirklichkeit die Benachrichtigungs-Routine vor der eigentlichen Methode aufgerufen würde. Das könnte sich aber kompliziert gestalten.

[hoika]

Hallo,

RTTI benutzen und schon mal 4 Wochen zum einarbeiten einplanen...


Heiko

[shmia]

Dieses zentrale Abfangen von Events geht in die Richtung Aspektorientierte Programmierung, dass Delphi aber leider nicht kann.
Viele Events in der VCL haben glücklicherweise eine virtuelle Funktion als Ursprungsquelle.
Beispiel für das Event OnHide:

Delphi-Quellcode:

TCustomForm = class(....)
...
protected
  procedure DoHide; dynamic;
...
end;
...
procedure TCustomForm.DoHide;
begin
  if Assigned(FOnHide) then FOnHide(Self);
end;

Also könnte man alle DoXXXXX Proceduren überschreiben.

So und nun noch etwas Programmier-Philosophie:
Du hast ein Problem damit, zu verstehen, wie die Events zeitlich abfolgen.
Anstatt nun dieses scheinbare "Problem" nur im konkreten Fall anzuschauen, versucht du es
durch weitere Programmierung allgemeingültig in den Griff zu kriegen.
Die Folge ist, dass du dir ein weit grösseres Problem (alle Event-Aufrufe zu verfolgen) damit geschaffen hast.
Das Ergebnis wäre dann "softwaretechnische Selbstbefriedigung" ohne konkreten Nutzen.
Wie so oft bringt dann der Computer Lösungen für Probleme, die es ohne Computer nie gäbe.

Ein erfahrener Programmierer würde die Eventreihenfolge einfach ignorieren.
Man braucht meistens (!!) gar nicht zu wissen in welcher Reihenfolge die Event abgefeuert werden.
Erst wenn man wirklich ein konkretes Problem hat, sollte man zuerst versuchen die Abhängigkeiten zwischen den Eventhandlern zu beseitigen.
Und wenn das nicht reicht, setzt man ein paar ShowMessage oder OutputDebugString in den Code und weiss dann Bescheid.
Siehe auch: KISS Prinzip.