Tool für DFM-Auswertung Komponenten-"Vernetzung"?

[Codehunter]

Hallo!

Zugegeben, mir ist kein gescheiter Titel für diesen Thread eingefallen. Ich arbeite an einem umfangreichen Projekt, bei dem Unmengen Komponenten (Datasets, Datasources, Actionmanager, Popupmenüs etc.) auf ein Form gelegt wurden. Bei manchen erschließt sich mir deren Zweck gar nicht, zumindest im PAS-Quelltext werden sie nicht verwendet. Gibt es evtl. ein Tool, welches die DFM auswertet und visualisiert, welche Komponenten mit welchen anderen Komponenten über Properties und den OI verbunden wurden? So etwas wäre praktisch, weil die DFM-Quellen "zu Fuß" durch zu gehen ist angesichts der Menge von nichtvisuellen Komponenten sehr aufwendig.

Grüße
Cody

[Uwe Raabe]

Das wäre doch mal eine schöne Idee für ein Plugin.

[haentschman]

Ich habe das gleiche Leiden. Ich traue mich nicht was wegzuwerfen was offensichtlich nicht in Benutzung ist. Ich helfe mir über eine Suche über alles.

[Pfaffe]

Ich habe ein Datamodul, welches von vielen Anwendungen verwendet wird. Da darf nicht weggeworden werden! Auch wenn von einer Anwendung vieles nicht benutzt wird. Schön wäre es, wenn der Linker nur die Sachen in die Exe baut, die auch benötigt werden.

[mjustin]

Mein OpenCTF Test Framework geht in diese Richtung.

Damit kann man z.B. alle 'verdächtigen' Komponenten finden bei denen eine Eigenschaft wie OnClick oder DataSource nicht zugewiesen sind. Das ganze arbeitet über dynamisch erzeugte DUnit-Testcases, man kann es daher in bestehende DUnit Testsuites integrieren.

Einige Tests sind bereits vordefiniert, man kann sich aber beliebige neue schreiben. Beispiel: alle Menüitems müssen einen OnClick-Handler haben, es sei denn sie enthalten ein Untermenü oder sie sind nur ein Separator:

Delphi-Quellcode:

function TMenuItemTests.Accepts(const Component: TComponent): Boolean;
begin
  Result := inherited Accepts(Component);

  // exclude menu items if they are separator lines or have submenu entries
  if Result then with TMenuItem(Component) do
    Result := (not IsLine) and (Count=0);
end;

procedure TMenuItemTests.AddTests;
begin
  inherited;

  CheckEvents(['OnClick']);
end;

https://github.com/michaelJustin/openctf

[Uwe Raabe]

Zitat von mjustin:

Damit kann man z.B. alle 'verdächtigen' Komponenten finden bei denen eine Eigenschaft wie OnClick oder DataSource nicht zugewiesen sind.

Der Pascal Analyzer von Peganza hat einen ähnlichen Missing Property Report und dazu passend auch einen inversen Property Value Report. (siehe Online Doku)

Das ist aber bei Weitem nicht das, was Cody sich vorstellt, oder?

[mjustin]

Zitat von Uwe Raabe:

Zitat von mjustin:

Damit kann man z.B. alle 'verdächtigen' Komponenten finden bei denen eine Eigenschaft wie OnClick oder DataSource nicht zugewiesen sind.

Der Pascal Analyzer von Peganza hat einen ähnlichen Missing Property Report und dazu passend auch einen inversen Property Value Report. (siehe Online Doku)

Das ist aber bei Weitem nicht das, was Cody sich vorstellt, oder?

Mit den Möglichkeiten sich die Tests maßzuschneidern (an Coding Standards anzupassen) hat OpenCTF eigentlich schon auch Vorteile gegenüber einem statischen Report oder einer vollständigen Visualisierung der Abhängigkeiten, die man dann doch wieder erst einmal 'zu Fuß' durcharbeiten muss, und das ja auch nach jeder Codeänderung.

Und: anstatt das DFM auszuwerten wird bei OpenCTF das instanziierte Formular oder Datenmodul betrachtet, d.h. Änderungen die sich durch das FormCreate ergeben sind auch berücksichtigt.

Aber sicher hat jedes Tool seine Vorzüge, es ist sicher interessant eine gelayerte Strukturdarstellung einer DFM mit allen Beziehungen der Komponenten zu erhalten.

[Codehunter]

Zitat von Uwe Raabe:

Zitat von mjustin:

Damit kann man z.B. alle 'verdächtigen' Komponenten finden bei denen eine Eigenschaft wie OnClick oder DataSource nicht zugewiesen sind.

Der Pascal Analyzer von Peganza hat einen ähnlichen Missing Property Report und dazu passend auch einen inversen Property Value Report. (siehe Online Doku)

Das ist aber bei Weitem nicht das, was Cody sich vorstellt, oder?

Das müsste ich mir im Detail anschauen. Spontan würde ich sagen, das was ich suche wäre genau der umgekehrte Fall: Nicht undefinierte Properties ausfindig machen sondern definierte, die auf TComponent-Abkömmlinge verweisen die auf dem Form/Datenmodul usw. liegen. Wenn dann Komponenten über bleiben, die keine "Connection" zu einer anderen Komponente/Control haben, dann wäre sie potentiell verwaist. Gibt natürlich auch solche wie z.B. das gute alte TXPManifest, die naturgemäß Einzelkinder sind. Aber zumindest hätte man mehr Überblick.

Das beschriebene Problem habe ich an vielen Stellen in einem großen Projekt, das ich sukzessive übernehme. Viele Altlasten und viel "mausprogrammiertes" Zeug.

[mjustin]

Zitat von Codehunter:

Wenn dann Komponenten über bleiben, die keine "Connection" zu einer anderen Komponente/Control haben, dann wäre sie potentiell verwaist.

Beispiele wären eine DataSource, die von keinem anderen Control mehr benutzt wird, oder eine Action, die keinem Button/Menüpunkt/... zugeordnet ist?

[Uwe Raabe]

Zitat von Codehunter:

das was ich suche wäre genau der umgekehrte Fall: Nicht undefinierte Properties ausfindig machen sondern definierte,

Deswegen ja auch dieser Hinweis:

Zitat von Uwe Raabe:

und dazu passend auch einen inversen Property Value Report