![]() |
AW: Überwachen von Objekteigenschaften
Bitte zitiere nicht jeden Beitrag einzeln ... ein Beitrag hätte auch gereicht.
Mehrfachposts wären hier nicht nötig gewesen. :warn: 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) |
AW: Überwachen von Objekteigenschaften
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
Delphi-Quellcode:
.
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:
Das ist die einzige Stelle im ganzen Programm, an der diese Buttons manipuliert werden.
procedure TImportDataForm.SetRunningState(running:Boolean);
begin BtnImport.enabled := not running; BtnStop.Enabled := running; BtnClose.Enabled := not running; LblZeitdauer.Visible := running; end; 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:
Sobald man zwei Punkte auf der linke Seite braucht (also Formular.Komponente.Property := Irgendwas) ist was faul im Staate Dänemark!
// Beispiel für ganz schlechten Programmierstil
Form5.Button11.Enabled := False; Form5.Button3.Enabled := True; Form5.ShowModal; Also ich verzichte gerne auf einen Debugger der alles kann und investiere meine Zeit in sauberen Sourcecode. |
AW: Überwachen von Objekteigenschaften
@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 :wink: Als Option fände ich eine solche Debug-Option durchaus nützlich. Man müsste sie ja nicht nutzen. |
AW: Überwachen von Objekteigenschaften
Darf ich bei diesem Punkt nochmals meine vormals gestellte Frage in den Raum werfen, warum keine Actions?
|
AW: Überwachen von Objekteigenschaften
Nepp, hier sind definitiv die Actions erste Wahl.
Vor allem das Event TAction.OnUpdate würde hier helfen diesen Bug in den Griff zu bekommen. Innerhalb des Events prüft man alle möglichen Statuswerte, die für die Action relevant sind und setzt dann die Eigenschaften (Enabled, Visible, Caption, etc.) für die Action, und der Drops ist gelutscht. Nun setzt keiner mehr die Eigenschaft des Buttons, sondern der Button passt sich von selbst an ;) |
AW: Überwachen von Objekteigenschaften
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:
Die hintere der beiden Zahlen notieren, die brauchen wir später noch.
btn1: TButton $123456 : $789ABC
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:
Jetzt haben wir alles zusammen. Nun setzen wir einen Breakpoint an der Adresse $00480834 und geben als Bedingung ein:
SetEnabled Controls.TControl.SetEnabled($480834)
Code:
Der Wert für EAX ist die oben notierte Zahl.
EAX=$00789ABC
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. |
AW: Überwachen von Objekteigenschaften
Hallo,
OldGrumpy: interessanter Aspekt des Debuggens, kannte ich noch nicht ... ;) Aber: Zitat:
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 |
AW: Überwachen von Objekteigenschaften
Zitat:
|
AW: Überwachen von Objekteigenschaften
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:wink:" bei, aber dennoch vielen Dank an alle, die wieder einmal konstruktiv zu dem Problem beigetragen haben! DANKE!!! |
AW: Überwachen von Objekteigenschaften
Das ist wirklich DIE Antwort, die dem gewünschten am nähesten kommt!
Kannte ich bisher noch nicht und daher: Super Antwort:thumb: 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. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 22:49 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024-2025 by Thomas Breitkreuz