Überwachen von Objekteigenschaften

[noisy_master]

Hallo Gemeinde,

gibt es in Delphi die Möglichkeit eine Art Breakpoint/TraceTrigger zu setzen wenn die Eigenschaft eines Objekts geändert wird?
Hintergrund der Frage: Ich erwarte z.B. dass ein Button disabled ist, er ist aber doch leider Enabled.
Nun würde ich gerne herausfinden welche der ~500 Stellen die den Button enablen können denn nun fälschlicherweise zuschlägt(ohne 500 breakpoints zu setzen zu müssen)

Danke im voraus für eure Hilfe.

[mleyen]

Delphi-Quellcode:

/// Ganz oben
type
  TButton = class(StdCtrls.TButton)
    procedure SetEnabled(Value: Boolean); override;
  end;

/// ...
/// Die eigentliche Unit...
/// ...

/// Vor end. dann:
{ TButton }

procedure TButton.SetEnabled(Value: Boolean);
begin
  inherited;
  if Self.Name = 'btnMeinBtnDerEnabledWird' then
    MessageDlg('Debugpoint hier setzen. :)', mtInformation, [mbOK], 0);
end;

tadaa 8-)

[DeddyH]

Was mir jetzt spontan einfällt: die Message CM_ENABLEDCHANGED abzufangen.

Delphi-Quellcode:

type
  TButton = class(StdCtrls.TButton)
  private
    FOnEnabledChanged: TNotifyEvent;
    procedure CMEnabledChanged(var Message: TMessage); message CM_ENABLEDCHANGED;
  public
    property OnEnabledChanged: TNotifyEvent read FOnEnabledChanged write FOnEnabledChanged;
  end;

  TFormTest = class(TForm)
  ...
  private
    { Private-Deklarationen }
    procedure DoOnChange(Sender: TObject);
  ...   


procedure TButton.CMEnabledChanged(var Message: TMessage);
begin
  inherited;
  if Assigned(FOnEnabledChanged) then
    FOnEnabledChanged(Self);
end;

procedure TFormTest.DoOnChange(Sender: TObject);
begin
  if Sender is TButton then
    ShowMessage(TButton(Sender).Name + ' hat sich geändert');
end;

procedure TFormTest.FormCreate(Sender: TObject);
begin
  Button1.OnEnabledChanged := DoOnChange;
end;

[noisy_master]

Danke, kling schon mal echt gut und dürfte für den Einzelfall das Mittel der Wahl sein.

Schön wäre es natürlich nun, wenn man nicht jede einzelne Eigenschaft für jede einzlen Klasse, die man überwachen möchte überschreiben müsste, sondern in der Art z.B. eines ExceptionHandlers einfach zu überwachende Eigenschaften auswählen könnte.
Kennt jemand dafür ein geeignetes Tooling/Expert/wizard?

Zitat:

Zitat von mleyen (Beitrag 1064236)

Delphi-Quellcode:

/// Ganz oben
type
  TButton = class(StdCtrls.TButton)
    procedure SetEnabled(Value: Boolean); override;
  end;

/// ...
/// Die eigentliche Unit...
/// ...

/// Vor end. dann:
{ TButton }

procedure TButton.SetEnabled(Value: Boolean);
begin
  inherited;
  if Self.Name = 'btnMeinBtnDerEnabledWird' then
    MessageDlg('Debugpoint hier setzen. :)', mtInformation, [mbOK], 0);
end;

tadaa 8-)

[stahli]

Das stimmt, ich hätte mir einen solchen Breakpint auch schon oft gewünscht.
Das würde die Laufzeit natürlich sehr ausbremsen, aber in bestimmten Fällen würde ich das gern mal in Kauf nehmen - natürlich nicht auf Dauer.
Der Debuger müsste an jeder Stelle (die einen Breakpoint erhalten KÖNNTE), die Erfüllung einer Bedingung prüfen und dann ggf. anhalten.

[Bummi]

Zitat:

Hintergrund der Frage: Ich erwarte z.B. dass ein Button disabled ist, er ist aber doch leider Enabled.
Nun würde ich gerne herausfinden welche der ~500 Stellen die den Button enablen können denn nun fälschlicherweise zuschlägt(ohne 500 breakpoints zu setzen zu müssen)

arbeitest Du nicht mit Actions ??

[himitsu]

Man könnte sich eine Klasse zusammenschreiben, welche die virtuellen Methoden, hier am Beispiel SetEnabled oder WndProc (die zentrale Nachrichtenbehandlung der Komponenten), zur Laufzeit "überschreibt", seinen eigenen Prüfcode einschleust und so leichter Debuggen kann.

Dieser Komponente wurde man dann sagen "Hooke mir die und die Methode jener Klasse".


evtl. gibt's sowas aber auch schon :stupid:

(über die neue 2010er/XE-RTTI würde sowas bestimmt ein Leichtes sein
und davor nur einen Hauch umständlicher/aufwändiger)


[add]
- "mit Debug-DCUs" in den Projektoptionen aktivieren (neuere Delphiversionen)
- in SetEnabled einen Haltepunkt sezten (wirkt natürlich nur, wenn die Änderung direkt über .Enabled reinkommt)
- die Bedingung für den Haltepunkt auf "Name = 'name der komponente'"
- und nun nur noch warten

Nicht wundern, aber dieses könnte das Programm ein bissl ausbremsen, da dieses natürlich von jedem kleinen Komponentchen aufgerufen wird.

[noisy_master]

Jupp ist richtig, aber wenn man sich solche "Komponenten" wie z.B. Eureka anschaut ist eine solche Funktion ganz hilfreich.

Zitat:

Zitat von stahli (Beitrag 1064245)

Das stimmt, ich hätte mir einen solchen Breakpint auch schon oft gewünscht.
Das würde die Laufzeit natürlich sehr ausbremsen, aber in bestimmten Fällen würde ich das gern mal in Kauf nehmen - natürlich nicht auf Dauer.
Der Debuger müsste an jeder Stelle (die einen Breakpoint erhalten KÖNNTE), die Erfüllung einer Bedingung prüfen und dann ggf. anhalten.

[noisy_master]

Ich muss zu meiner Schande gestehen: NEIN!
Aber wie sollte das bei diesen Probleme helfen?

Zitat:

Zitat von Bummi (Beitrag 1064247)

Zitat:

Hintergrund der Frage: Ich erwarte z.B. dass ein Button disabled ist, er ist aber doch leider Enabled.
Nun würde ich gerne herausfinden welche der ~500 Stellen die den Button enablen können denn nun fälschlicherweise zuschlägt(ohne 500 breakpoints zu setzen zu müssen)

arbeitest Du nicht mit Actions ??

[noisy_master]

Ja klingt plausibel.

Genau dieses "EVTL" suche ich :-D

Zitat:

Zitat von himitsu (Beitrag 1064249)

Man könnte sich eine Klasse zusammenschreiben, welche die virtuellen Methoden, hier am Beispiel SetEnabled oder WndProc (die zentrale Nachrichtenbehandlung der Komponenten), zur Laufzeit "überschreibt", seinen eigenen Prüfcode einschleust und so leichter Debuggen kann.

Dieser Komponente wurde man dann sagen "Hooke mir die und die Methode jener Klasse".


evtl. gibt's sowas aber auch schon :stupid:

(über die neue 2010er/XE-RTTI würde sowas bestimmt ein Leichtes sein
und davor nur einen Hauch umständlicher/aufwändiger)