Debug Visualizers für Interfaces?

[stahli]

Deine Frage verstehe ich nicht ganz, aber bringt Dich das vielleicht weiter?
http://www.delphipraxis.net/189852-u...ptimieren.html

EDIT: Habe den Thread nochmal überflogen. Du hast offenbar genau das gleiche Problem wie ich damals. Also sollte die Antwort passen.

[Mavarik]

Zitat von stahli:

Deine Frage verstehe ich nicht ganz, aber bringt Dich das vielleicht weiter?
http://www.delphipraxis.net/189852-u...ptimieren.html

EDIT: Habe den Thread nochmal überflogen. Du hast offenbar genau das gleiche Problem wie ich damals. Also sollte die Antwort passen.

Nein... Ich habe mir natürlich den Thread schon angesehen, bevor ich hier die Frage gepostet habe.

Das Funktioniert natürlich nur, wenn das Interface auch eine Methode .AsString hat... Jetzt kann man natürlich sagen, dann verpasse ich meinem Interface halt so eine Methode.

Wäre sicherlich auch die bessere Stelle als im Visualizer... Aber dann kann ich auch im "Fenster der Überwachten Ausdrücke" MyInterface.AsString schreiben und brauche keine Visualizer mehr...
(Abgesehen vom Maus-Over Display)

Oder übersehe ich etwas?

Ich hatte gehofft es gibt sowas wie:

Delphi-Quellcode:

Var
  LocalInterface : IMyInterface;
begin
  LocalInterface := CurThread.Evaluate(Expression+'.Instance');
  Result := LocalInterface.Foo+' '+LocalInterface.Bar+' Cool : '+LocalInterface.Fancy;
end;

Ich habe in meinem FDK viele Interfaces und möchte diese "korrekt" im Fenster der Überwachten Ausdrücke darstellen - und das auch ohne, dass der User eine .AsString implementieren muss. (Jetzt könnte man natürlich sagen... So kann der User sich das besser anpassen... Tja, es gibt immer zwei Seiten...)

Mavarik

PS. In der "case EvalRes of" fehlter das erError, daher hatte ich auch nie ein Ergebnis.
bzw. Lustig das alle das begin end innerhalb des Repeats aus dem Beispiel mit kopieren...

PPS.: Oh - man könnte natürlich auch eine .ToJSON verwenden um im Visualizer die Instance ab zu bilden...

[Mavarik]

OK ein Visualizer hat doch Vorteile - Vorausgesetzt das Interface hat eine AsString Methode...

Eine Variable

Delphi-Quellcode:

var
  Foo : TArray<IMyInterface>

Wird dann auch richtig dargestellt...

Oder auch ein anderes Interface

Delphi-Quellcode:

var
  ListFoo : IMyListinterface;  // Function Many(AFoo : IMyInterface) : TArray<IMyInterface>;
  Foo     : IMyInterface;

Wenn man dann ListFoo.Many(Foo) als Watch-Variable nimmt und Funktionsaufrufe erlaubt, Erhält man eine "richtige" Liste...

Nice...

Mavarik

[himitsu]

Das sind doch Delphi-Interfaces?

Nja, der Visualizer für Öbjekte ist zwar auch nicht immer so optimal,
aber was pasiert, wenn du sowa wie CurThread.Evaluate(Expression+' as TObject') versuchst?

[Mavarik]

Zitat von himitsu:

Das sind doch Delphi-Interfaces?

Nja, der Visualizer für Öbjekte ist zwar auch nicht immer so optimal,
aber was pasiert, wenn du sowa wie CurThread.Evaluate(Expression+' as TObject') versuchst?

ok... Das Ergebnis wäre jedenfalls kein String...

hmm dann mit ResultAddr und casten? Ich dachte man kommt nicht an den Speicherbereich?

Delphi-Quellcode:

var
  Instance : TFoo absolute ResultAddr;

Sowas? Muss ich testen

[Zacherl]

Zitat von Mavarik:

Ich dachte man kommt nicht an den Speicherbereich?

An den Speicherbereich zum Objekt, das vom Interface gekapselt wird? Hatte irgendwo in einem Thread auf Stackoverflow mal gelesen, dass die einzig saubere Methode wohl das Implementieren einer Methode/Property function GetObject: TObject ist, welche in der konkreten Implementation des Interfaces dann Self zurückgibt. Mal schauen, ob ich den Thread noch irgendwie finde; dort stand glaube ich auch beschrieben, was die Problematik bei normalen Casts war.

Edit:
http://stackoverflow.com/questions/4...ject-in-delphi

Ist allerdings auch schon ein älterer Thread, kann sein, dass sich da mitlerweile was geändert hat.

Edit 2:
Ab D2010 kannst du scheinbar auch den as Operator verwenden (vermutlich aber weniger performant).

[Mavarik]

Zitat von Zacherl:

An den Speicherbereich zum Objekt, das vom Interface gekapselt wird? Hatte irgendwo in einem Thread auf Stackoverflow mal gelesen, dass die einzig saubere Methode wohl das Implementieren einer Methode/Property function GetObject: TObject ist, welche in der konkreten Implementation des Interfaces dann Self zurückgibt. Mal schauen, ob ich den Thread noch irgendwie finde; dort stand glaube ich auch beschrieben, was die Problematik bei normalen Casts war.

Edit 2:
Ab D2010 kannst du scheinbar auch den as Operator verwenden (vermutlich aber weniger performant).

(Edit2) as soll weniger performant sein? OK...

Ich erkenne gerade den Nachteil meiner Idee... Falls das funktioniert. Ich muss dann ja wenigstens eine Implementation des Interfaces mit kompilieren.
ggf. hat das ungewollte Effekte... Abgesehen vom "Rattenschwanz" was noch automatisch mit kommen würde. e.g.

- Logging
- Multilinguale Exceptions
- Factory's
- uvm...

Generische Interfaces würden sowieso dann rausfallen...

Ich muss das erstmal alles gegeneinander abwägen. (Und testen)


Mavarik

[Zacherl]

Zitat von Mavarik:

(Edit2) as soll weniger performant sein? OK...

Jaa, die erste Variante ist ein einfacher Methodenaufruf, während an as noch ein ganzer Rattenschwanz anhängt:

Zitat:

This as operator use a special hidden interface GUID (ObjCastGUID ) to retrieve the object instance, calling an enhanced version of TObject.GetInterface