Debuger und Eigenschaften der Komponenten

[six1]

Hi,
wahrscheinlich habe ich es schon mal irgendwann gefragt; habe es auf jeden Fall vergessen oder keine befriedigende Antwort bekommen, welche ich mir gemerkt habe

Warum werden Eigenschaften von Komponenten nicht angezeigt?
Vielleicht kann mir das mal jemand schlüssig erklären...

Image4.jpg (24.58 KiB) 2753 mal betrachtet

Image5.jpg (61.63 KiB) 2753 mal betrachtet

Image6.jpg (42.13 KiB) 2753 mal betrachtet

Warum wird bei Label1.caption kein Wert gezeigt?

[fliegermichl]

Der Debugger kann nur Properties anzeigen, die direkt auf ein Feld zeigen. Wenn der Inhalt über eine Gettermethode geholt wird, kann er es nicht.
Warum ist mir auch ein Rätsel.
Delphi 5 konnte das schon 1998

[six1]

Jetzt erinnere ich mich dunkel
Ich denke, das hat schon in D2 funktioniert!

Danke @fliegermichl

[wp_xyz]

Ich stelle mir das höchst kompliziert vor: Da muss der Debugger den Code ausführen, der dem Getter zugeordnet ist. Im Getter ist aber alles erlaubt, insbesondere können Variablen verändert werden, und diese werden den späteren Verlauf des Programms verändern.

Und Delphi kann das auch nicht immer so problemlos. Ich habe immer wieder Fälle, bei denen das Popup-Fenster für den Wert eines Propery nichts anzeigt.

[six1]

Und Delphi kann das auch nicht immer so problemlos. Ich habe immer wieder Fälle, bei denen das Popup-Fenster für den Wert eines Propery nichts anzeigt.

Naja, einigen wir uns auf: Meist funktioniert es.

Unter Lazarus aber nie

Oft muss ich extra eine lokale Variable definieren oder sonstige Umwege gehen.

Wie geht ihr damit um? Habt ihr das Problem nicht?

[wp_xyz]

Wie geht ihr damit um? Habt ihr das Problem nicht?

- WriteLn, oder - besser - DebugLn
- Hilfsvariable für Mouse-Over
- Objekt-Variable in "Evaluate/Modify" oder in "Watch", d.h. Label1.FCaption statt Label1.Caption

[six1]

Also umschiffst du das Problem auch in gleicher Weise...

[af0815]

Ich habe das bis D8 mit dem Debugger selbst erleben dürfen, so gross ist der Unterschied zum aktuellen Lazarus nicht wirklich. Zumindest bin ich mit Lazarus zufrieden. Und beim Crosscompiling kann man sowieso schlechter debuggen. Mit dem remote GDB hat man eine Chance, falls man sich den richtigen remote GDB bauen kann. Für mich ist mittlerweile LazLogger der beste Freund.

[PascalDragon]

Unter Lazarus aber nie

Wie wp_xyz bereits angedeutet hat: weil das eben ein komplexes Problem ist. Wäre es einfach zu lösen, dann hätten wir es bereits, weil es ja bekanntlich so nützlich ist.

Um mal die Probleme aufzulisten:

• Der Debugger muss erkennen können, dass es sich um eine Eigenschaft handelt und ob er sie mittels eines Feldes oder eines Methodenaufrufs ermitteln kann (hier ist auch noch die Unterscheidung statisch oder virtuell wichtig), das heißt dies muss entsprechend in der Debuginformation hinterlegt sein (heißt der Compiler muss es auf eine Art generieren, die es dem Debugger erlaubt diese Information an die IDE weiter zu geben)
• Der Debugger muss die Möglichkeit haben Methoden aufzurufen. GDB hat diese Fähigkeit prinzipiell, aber es muss dennoch ein korrekter Stack erzeugt werden und die Parameterübergabekonvention muss korrekt erfüllt werden (das heißt dies ist noch dazu sehr plattformabhängig und muss auch für jede Aufrufkonvention gemacht werden)
• Es muss sichergestellt werden, dass der Debugger bzw. die IDE nicht hängen bleibt (was wenn zum Beispiel ein Getter aufgerufen wird der eine TCriticalSection nutzt, diese aber gleichzeitig vom Code der debugged wird auch betreten wurde?)

Das ist jetzt natürlich nur ein grober Überblick und es werden auch immer wieder Schritte gemacht dies zu ermöglichen (v.a. mit FpDebug), aber es ist eben nicht einfach und es müssen mehrere Komponenten (Compiler, Debugger, IDE) hier zusammen spielen.

Joost van der Sluis ist derjenige von uns der da hauptsächlich an der Thematik arbeitet und es gibt da durchaus entsprechende Fortschritte (zum Beispiel hier - das ist zwar in Visual Studio Code nutzt aber FpDebug - oder hier zur Verbesserung der Debugschnittstelle innerhalb von Lazarus in Vorbereitung auf das alles).

[martin_frb]

Delphi nutzt weder stabs noch dwarf....

stabs und dwarf haben keine Definition für "Properties".

Damit das funktioniert:
- Muss der Compiler zusätzliche Info generieren (Joost arbeitet daran / Dwarf extension)
- Der Debugger diese lesen (kommt dann als nächstes)
- Der Debugger Funktionen aufrufen können (funktioniert teilweise bereits, dank Joost)

FpDebug kann derzeit (in 2.2) bestimmte Funktionen aufrufen, wenn die Argumente, und Result alle in Register passen, und NICHT "managed" (oder referenced) sind.

Allerdings schreibt der Compiler derzeit nicht für alle Methoden einer Klasse vollständige infos.....

[fliegermichl]

Das lässt hoffen. Danke für die Informationen.

[six1]

Ah, das hört sich sehr gut an, Danke

[af0815]

Der Screencast für die Debuggerschnittstelle sieht schon sehr gut aus. Das lässt auf sehr viel Komfort und Information hoffen.
Auch interessant zu sehen, wie ein Pascalprogramm durch VSC ausgeführt und debugged wird.

Danke für den interessanten Einblick in die Zukunft.

[m.fuchs]

wp_xyz hat ja schon angedeutet, dass es zu Seiteneffekten kommen kann. Nehmen wir mal folgende Klasse:

Code: Alles auswählen

type
  TMyClass = class(TObject)
    private
      FMyString: String;
      FMyStringReadCount: Integer;
    private
      function GetMyString: String;
      procedure SetMyString(AValue: String);
    public
      constructor Create;
    public
      property MyString: String read GetMyString write SetMyString;
      property MyStringReadCount: Integer read FMyStringReadCount;
  end;

function TMyClass.GetMyString: String;
begin
  Inc(FMyStringReadCount);
  Result := FMyString;
end;

procedure TMyClass.SetMyString(AValue: String);
begin
  if FMyString = AValue then Exit;
  FMyStringReadCount := 0;
  FMyString := AValue;
end;

constructor TMyClass.Create;
begin
  inherited Create;
  FMyString := 'Test';
  FMyStringReadCount := 0;
end;

Ich habe die Property MyString die eine Zeichenkette enthält, sowie die Property MyStringReadCount die angibt wie oft auf MyString lesend zugegriffen wurde (nach dem letzten Schreibzugriff).
Wenn ich jetzt also per Debugger auf MyString zugreife, wird sich auch dieser Wert ändern. Damit liefert der Debugger nicht nur eine Einsicht in den Zustand meines Systems, er verändert es. Im Grunde ist das dann Schrödingers Katze. Ich verändere das System um seinen Zustand in Erfahrung zu bringen.

Und jetzt kommen wir zu der eigentlichen Frage: Warum brauche ich überhaupt einen Debuggerzugriff auf eine Property?
Es fällt mir jetzt eigentlich kein sinnvoller Grund ein. Die Daten sind ja in irgendwelchen Feldern abgelegt, also muss ich auch nur diese Felder auswerten.

[six1]

Warum brauche ich überhaupt einen Debuggerzugriff auf eine Property?

Ich weiß nicht, warum du es brauchen könntest.

Ich benötige beim Debuggen manchmal Informationen über Eigenschaften von Objekten.
Hier geht es dann nur über Umwege im Moment.