Überwachen von Objekteigenschaften

[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 ??

[noisy_master]

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

Zitat von 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

(ü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]

Ja klingt plausibel.

Genau dieses "EVTL" suche ich

Zitat von 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

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

[himitsu]

Bitte zitiere nicht jeden Beitrag einzeln ... ein Beitrag hätte auch gereicht.
Mehrfachposts wären hier nicht nötig gewesen.
Und komplette Beiträge zu zitieren ebenso wenig.

PS: Ich hatte oben, in meinem letzen Beitrag, noch was dazugeschrieben.
(ohne Garantie, ob's so funktioniert)

[shmia]

Manche Programmierer verbringen viel Zeit mir ihrem Debugger; Andere versuchen lieber ihre Software "wartungsfreundlich" und sauber zu designen.

Wenn ich einen Button en/disable dann achte ich darauf wie oft ich das tue.
Beim ersten Mal schreibe ich direkt hin BtnImport.Enabled := False; .
Spätestens aber beim 3. Mal mache ich mir Gedanken und zentralisere die Geschichte.
In folgendem Szenario gibt es z.B. 3 Buttons - Importieren, Stop und Schliesen.

Delphi-Quellcode:

procedure TImportDataForm.SetRunningState(running:Boolean);
begin
   BtnImport.enabled := not running;
   BtnStop.Enabled   := running;
   BtnClose.Enabled  := not running;
   LblZeitdauer.Visible := running;
end;

Das ist die einzige Stelle im ganzen Programm, an der diese Buttons manipuliert werden.
Was könnte einfacher sein als jetzt einen Breakpoint zu setzen?

Ich würde auch nie auf die Idee kommt z.B. folgendes zu Schreiben:

Delphi-Quellcode:

// Beispiel für ganz schlechten Programmierstil
Form5.Button11.Enabled := False;
Form5.Button3.Enabled := True;
Form5.ShowModal;

Sobald man zwei Punkte auf der linke Seite braucht (also Formular.Komponente.Property := Irgendwas) ist was faul im Staate Dänemark!


Also ich verzichte gerne auf einen Debugger der alles kann und investiere meine Zeit in sauberen Sourcecode.

[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

[Bummi]

Darf ich bei diesem Punkt nochmals meine vormals gestellte Frage in den Raum werfen, warum keine Actions?