Hi,

ich hatte mal so eine spontane Idee mit der man die Debugging Experience in Delphi verbessern kann. Hab mich dann mal schnell ein Bisschen in die OpenTools API eingelesen und raus kam eine allererste Demo-Version der Delphi Debugger Visualizer.

Sinn des Ganzen? Ähnlich wie in Visual Studio 2005 soll diese IDE Erweiterung einem einfach dabei helfen, seine Variablen zu analysieren. Als Proof-Of-Concept hab ich mir einmal TStringList vorgenommen (siehe angehängten Screenshot).

Den Sourcecode zu dem Package habe ich auch angehängt. Zum Installieren einfach die Projektdatei öffnen, und auf Installieren klicken (wie eben bei Packages so üblich). Der Menüpunkt selbst ist versteckt unter "Help/Inspect...".

Ich möchte darauf hinweisen, dass dies Beta-Software ist. Zum Inspizieren von StringLists und multi-line strings sollte es aber schon allemal reichen.

Ich hoffe,
a) so etwas finden auch andere praktisch
b) sowas gibt's nicht schon


Grüße
Daniel

Zitat von Lemmy1:

a) so etwas finden auch andere praktisch

Ich finde gerade das bessere darstellen von Stringlisten extrem praktisch!

Läuft das auch unter D2005? Der Screenshot zeigt ja D2006 (oder ist es Turbo)?

Sehr sinnvoll wäre auch, wenn man die Stringliste noch in eine Datei speichern könnte.

Ciao,
Ralf

Zitat von Alfi001:

Zitat von Lemmy1:

a) so etwas finden auch andere praktisch

Ich finde gerade das bessere darstellen von Stringlisten extrem praktisch!

Läuft das auch unter D2005? Der Screenshot zeigt ja D2006 (oder ist es Turbo)?

Sehr sinnvoll wäre auch, wenn man die Stringliste noch in eine Datei speichern könnte.

Ciao,
Ralf

Ausprobiert habe ich es nicht unter Delphi 2005. Die OpenTools API ist bekanntermaßen der fehlerbehaftetste (schreibt man das so?) Teil von Delphi, somit müsste das einfach mal jemand ausprobieren.

Mit dem Speichern in eine Datei hast Du sicher recht. Dazu werde ich mir mal was überlegen. Außerdem möchte ich ein besseres Control zur Darstellung verwenden (mit Sortierung, Darstellung vom angehängten Objekt etc)

Ich bin auch noch am überlegen, welche Datentypen man sonst noch direkt unterstützen könnte. Dazu fällt mir ein:

• TStringList (gibt's bereits rudimentär)
• TObjectList (wobei man dann auf ein Objekt doppelklicken könnte...dadurch würde dies im Visualizer selbst erscheinen)
• string (gibt's auch schon und hat den Vorteil, dass es multi-line kann). Wäre vielleicht auch noch praktisch, wenn man den String XML interpretiert darstellen könnte
• DataSet?
• ADO RecordSet?

Hat jemand sonst noch gute Ideen dazu?


Ein weiteres Problem ist, dass ich nur die "Evaluate" Funktion verwenden kann, um an die Daten zu kommen. Das mache im Moment so:

• Eingegeben Ausdruck erst einmal direkt auswerten. Bei Fehler --> sofort abbrechen
• Ausdruck einklammern und ClassName anhängen. '(' + Expression + ').ClassName'. Bei Fehler --> kein Objekt --> String direkt anzeigen. Wenn kein Fehler --> Objektklasse prüfen (bisher wird nur TStringList erkannt)
• Für TStringList: Via '(' + Expression + ').Count' erhalte ich die Länge und via '(' + Expression + ')[XX]' erhalte ich die Elemente.

Das funktioniert prinzipiell auch ganz gut, hat aber ein großes Performanceproblem. Ich hab auch mal "CommaText" ausprobiert, aber das wird leider rausoptimiert wenn man es nicht verwendet...auch blöd Mir ist aber aufgefallen, dass man via "Evaluate" auch an private Variablen ran kommt (und sowas kann ja nicht rausoptimiert werden). So könnte man an alle Elemente auf einmal kommen und sollte keine Performanceprobleme mehr haben (theoretisch ) Werd damit noch ein Bisschen rumspielen, weil die aktuelle Performance schrottig ist.

Hat sowas schon einmal jemand gemacht? Vielleicht übersehe ich ja eine simple Sache...?

Hey, sowas in der Art ist echt praktisch

Von Haus aus kann man ja z.B. bei TStringList nur rausfinden, wie viele Einträge sie hat, aber an die werte zu kommen gibts ncihtmal ne komplizierte Möglichkeit oder

Wenn aus der allerersten Demo mal ein vollwertiges Produkt wird bin ich Stammkunde

btw: Mitentwickler suchst du nciht zufällig einen

Zitat von Meflin:

Von Haus aus kann man ja z.B. bei TStringList nur rausfinden, wie viele Einträge sie hat, aber an die werte zu kommen gibts ncihtmal ne komplizierte Möglichkeit oder

Was ist an "SL[0]" so kompilziert?



Ein "In Zwischenablage kopieren" Button für die StringList wäre auch nicht schlecht. Ich muss jedesmal die #13#10 aus dem TSQLQuery.SQL.Text entfernen wenn ich das SQL Statement in einem anderen Programm testen will.

Zitat von Meflin:

Hey, sowas in der Art ist echt praktisch

Von Haus aus kann man ja z.B. bei TStringList nur rausfinden, wie viele Einträge sie hat, aber an die werte zu kommen gibts ncihtmal ne komplizierte Möglichkeit oder

Wenn aus der allerersten Demo mal ein vollwertiges Produkt wird bin ich Stammkunde

btw: Mitentwickler suchst du nciht zufällig einen

Na das freut mich Kann man solche Packages eigentlich auch Quellcode irgendwie sinnvoll deployen?

Zitat von jbg:

Was ist an "SL[0]" so kompilziert?

Da zeigt mein Debugger nichts an

(Wenn man z.B. eine StringList in einer Schleife durchläuft und den Wert abfragen will)

Zitat:

Kann man solche Packages eigentlich auch Quellcode irgendwie sinnvoll deployen?

Äh... was bitte

Zitat von Meflin:

btw: Mitentwickler suchst du nciht zufällig einen

Whopps das hab ich ja komplett überlesen in der Schriftgröße. Klar hätt ich gern nen Mitentwickler. Dann hängen wir uns da zu zweit für 2 Monate rein und haun das dann für 9,99€ im Dreierpack über die Ladentheke

Zitat von Meflin:

Von Haus aus kann man ja z.B. bei TStringList nur rausfinden, wie viele Einträge sie hat, aber an die werte zu kommen gibts ncihtmal ne komplizierte Möglichkeit oder

Versuch doch mal, 'ShowMessage(MyStringList.Text)', oder 'MyStringList.SaveToFile('Foobar.TXT')' im Inpsect/Modify Dialog...

Ansonsten: Lustiges 'Proof-Of-Concept'... müsste man aber ausbauen, denn für die paar mal, wo man sich alle(!) Elemente einer Stringliste anschauen muss, reichen imho o.g. Tricks.

[quote="alzaimar"]

Zitat von Meflin:

Ansonsten: Lustiges 'Proof-Of-Concept'... müsste man aber ausbauen, denn für die paar mal, wo man sich alle(!) Elemente einer Stringliste anschauen muss, reichen imho o.g. Tricks.

Es gibt ja nicht nur TStringList. Wart erst mal ab, bis Du Dich dran gewöhnt hast, Xml im String auch Xml formatiert zu sehen. Oder DataSets mit allen Tabellen in einem Fenster etc etc. Visual Studio 2005 hat da schon hervorragende Ansätze