Überwachen von Objekteigenschaften

[stahli]

@shima
Häng Dich doch mal nicht an dem Button auf...
Es kann doch auch um andere Variablen oder Eigenschaften gehen, deren Werte "irgendwo" unerwartet verändert werden.
Wenn Du keine Fehler in der Programmentwicklung machst, dann gehe ich mal bei Dir in Schulung
Als Option fände ich eine solche Debug-Option durchaus nützlich. Man müsste sie ja nicht nutzen.

[shmia]

Zitat von stahli:

@shima
Häng Dich doch mal nicht an dem Button auf...
Es kann doch auch um andere Variablen oder Eigenschaften gehen, deren Werte "irgendwo" unerwartet verändert werden.

Ok, es gibt Klassen, Properties, Proceduren und Funktionen in die man nicht hineindebuggen kann; also kurz gesagt Code, der nicht unter der eigenen vollständigen Kontrolle steht.
Dazu gehört z.B. die Windows API, ActiveX und Komponenten aus der VCL.
Ja, man kann mit Debug-DCUs kompilieren aber es handelt sich doch um fremden Code.

Im Laufe der Jahre habe ich gelernt mit diesem "Fremdcode" umzugehen.
Falls nötig baue ich um diesen Fremdcode eine Schicht, die meistens aber nur hauchdünn ist.
Es ist wichtig zu erkennen, wann man die Schicht braucht und wann nicht.
Die Schicht kann manchmal auch nur eine Funktion sein, die ein Argument 1 zu 1 weiterleitet.

Delphi-Quellcode:

Beispiel
procedure TForm1.ShowError(const msg:string);
begin
  ShowMessage(msg);
  // oder
  // Statusbar1.SimpleText := msg;
end;

Diese Schicht ist sehr dünn, aber ich kann einen Breakpoint setzen oder die Fehlermeldung auf eine andere Weise anzeigen.

Für den Zugriff auf Komponenten habe ich meistens keine Zwischenschicht.
Nur falls nötig oder falls ein Spareffekt (z.B. mehrere Buttons auf einen Rutsch dis/enablen) eintritt würde ich eine Procedure/Funktion als Zwischenschicht einführen.

Ganz anderst sieht das mit Handles und Zeigern der Windows API aus.
Hier kapsele ich grundsätzlich immer mit einer Klasse, Procedure oder Funktion.
Stellt euch vor es gäbe die Klassen TFont, TCanvas, TPen und TBrush nicht.
Was wäre das für eine Qual irgendetwas zu zeichnen.

Ähnlich sieht das bei Zeigern und Strukturen aus der Windows API aus.
Ich würde z.B. niemals die Windows API-Funktion GetComputerName() direkt in meiner Anwendung aufrufen.
Nein, dieser Aufrauf braucht eine kleine Zwischenschicht:

Delphi-Quellcode:

function GetLocalComputerName: string;
var
  Count: DWORD;
begin
  Count := MAX_COMPUTERNAME_LENGTH + 1;
  SetLength(Result, Count);
  if GetComputerName(PChar(Result), Count) then
    StrResetLength(Result)
  else
    Result := '';
end;

Ich würde auch nie auf die Idee kommen meine Anwendung direkt mit WinSock-Funktionen (socket(),bind(),listen(),..) oder Funktionen für die serielle Schnittstelle reden zu lassen.
Hier braucht es unbedingt eine Klasse, die den Zugriff kapselt.
Automatisch habe ich dadurch Code auf den ich Breakpoints setzen kann.

Fazit: um Code, der nicht unter der eigenen Kontrolle steht sollte man (bei Bedarf) eine Zugriffsschicht legen.
Die dünnstmögliche Schicht ist die 1:1 Weiterleitung einer Funktion/Procedure