Überwachen von Objekteigenschaften

[OldGrumpy]

Das geht auch mit den Bordmitteln des Debuggers, ohne sich Code zu schreiben. Am Beispiel von TButton erklärt:

- Breakpoint in der Applikation an einer Stelle setzen wo das Ziel-Control schon existiert und inspiziert werden kann. Z.B. für einen Button im OnActivate des jeweiligen Forms, die Möglichkeiten sind zahlreich. Rechtsklick auf den Namen des Controls im Source und das Control inspizieren. Ganz oben im Inspektorfenster steht jetzt beispielsweise:

Code:

btn1: TButton $123456 : $789ABC

Die hintere der beiden Zahlen notieren, die brauchen wir später noch.

Nun auf den Reiter "Methoden" klicken, und dort - um im obigen Beispiel zu bleiben - "SetEnabled" suchen. Die Zeile sieht bei TButton z.B. so aus:

Code:

SetEnabled    Controls.TControl.SetEnabled($480834)

Jetzt haben wir alles zusammen. Nun setzen wir einen Breakpoint an der Adresse $00480834 und geben als Bedingung ein:

Code:

EAX=$00789ABC

Der Wert für EAX ist die oben notierte Zahl.

Nun kann man den oben zuerst gesetzten Breakpoint wieder entfernen und das Programm laufen lassen. Immer wenn das Property Enabled des oben herausgesuchten TButton gesetzt wird, triggert nun der Breakpoint. Das lässt sich sicherlich auch in einen Experten gießen, aber wenn man das ein paar Mal gemacht hat, geht das so flott von der Hand dass ich bisher noch nicht weiter drüber nachgedacht hab, diese vier Schritte noch weiter zu automatisieren. Und es geht auf jeden Fall schneller als sich erst jedes Mal einen Class Helper zu schreiben.

Nachtrag: Diese Methode funktioniert recht universell für alle möglichen Objekte (nicht nur Controls) und deren Properties, geht also in den Debuggingmöglichkeiten noch viel weiter als die Methode mit den Actions.

[hoika]

Hallo,

OldGrumpy:
interessanter Aspekt des Debuggens,
kannte ich noch nicht ...

Aber:

Zitat:

Es kann doch auch um andere Variablen oder Eigenschaften gehen, deren Werte "irgendwo" unerwartet verändert werden

Es gibt kein "irgendwo".
Verändere ich an zwei unterschiedlichen Stellen eine Variable direkt (auch ein Property eines fremdem Objektes),
habe ich was was falsch gemacht.
-> Methode schreiben.


Heiko

[OldGrumpy]

Zitat von hoika:

Zitat:

Es kann doch auch um andere Variablen oder Eigenschaften gehen, deren Werte "irgendwo" unerwartet verändert werden

Es gibt kein "irgendwo".
Verändere ich an zwei unterschiedlichen Stellen eine Variable direkt (auch ein Property eines fremdem Objektes),
habe ich was was falsch gemacht.
-> Methode schreiben.

Doch, "irgendwo" gibt es sehr wohl. Sollte zwar nicht vorkommen, passiert aber durchaus mal. Um solche "wilden" Zugriffe einzukreisen, gibt es Data Breakpoints. Die greifen halt nicht, wenn Code an einer bestimmten Adresse ausgeführt wird, sondern wenn eine bestimmte Adresse gelesen und/oder geschrieben wird (je nach Wunsch.) Damit bekommt man heraus, warum z.B. eine Variable auf einmal einen völlig falschen Wert hat. Tritt gerne auf wenn man mit Pointern oder Arrays arbeitet Natürlich ist das im Endeffekt ein Fehler, man hat also was falsch gemacht, aber eine Methode zu schreiben bringt einen dem Fehler keinen Schritt näher in diesem Fall. Ein Objekt kann sich ja (okay, Massnahmen aus dem Bereich Software Protection mal außen vor gelassen) gar nicht gegen Schreibzugriffe auf seinen Speicherbereich "von außen" wehren, es bekommt davon ja gar nichts mit.

[noisy_master]

Hallo liebe Delphi Gemeinde,

ich denke wir sollten den Thread an dieser Stelle beenden, weil doch viele hilfreiche Anregungen gekommen sind. Leider war nicht die "ultimative Lösung mit der alles von selbst geht" bei, aber dennoch vielen Dank an alle, die wieder einmal konstruktiv zu dem Problem beigetragen haben!

DANKE!!!

[noisy_master]

Das ist wirklich DIE Antwort, die dem gewünschten am nähesten kommt!

Kannte ich bisher noch nicht und daher: Super Antwort

Schönen Dank auch nochmal für das hilfreich in Die Seite treten bzgl. "Irgendwo im Code gibt es nicht"
Hast recht ist zwar kein gutes Design, manchmal muss es aber halt sein.

[Luckie]

Zitat von noisy_master:

Hast recht ist zwar kein gutes Design, manchmal muss es aber halt sein.

Es gibt keinen guten Grund für schlechtes Design. Wenn man aus Zeitdruck mal schlechten Code schreiben muss OK, aber das Design macht man ja schon vorher.

[DeddyH]

Wenn man Projekte von anderen übernimmt, muss man wohl oder übel auch das ggf. miese Design übernehmen, es sei denn, man hat sehr viel Zeit (wer hat die schon?).

[Luckie]

Das ist was anderes. Aber offensichtlich handelt es sich um sein eigenes Projekt. Aber auch Refactoring kann Zeit sparen. Ich habe mal Code vom Kollegen bekommen, den er so runtergetippt hatte. Dieser Code sollte jetzt erweitert werden. Ich glaube es waren sechs Stunden veranschlagt. Ohne Refactoring hätte ich das in den sechs Stunden nicht geschafft. Weil keine Struktur drin war. Und beim verstehen ist das Refactoring fast von alleine gegangen. Vom ursprünglichen Code ist eigentlich nur der rein funktionale Code übrig geblieben.