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]

:thumb: 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:

Zitat von mjustin (Beitrag 1426423)

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:

Zitat von Uwe Raabe (Beitrag 1426425)

Zitat:

Zitat von mjustin (Beitrag 1426423)

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:

Zitat von Uwe Raabe (Beitrag 1426425)

Zitat:

Zitat von mjustin (Beitrag 1426423)

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:

Zitat von Codehunter (Beitrag 1426429)

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:

Zitat von Codehunter (Beitrag 1426429)

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

Deswegen ja auch dieser Hinweis:

Zitat:

Zitat von Uwe Raabe (Beitrag 1426425)

und dazu passend auch einen inversen Property Value Report

[Codehunter]

Zitat:

Zitat von mjustin (Beitrag 1426430)

Zitat:

Zitat von Codehunter (Beitrag 1426429)

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?

Bekannte Beispiele, ja. In meinem Fall sind es weniger bekannte Drittanbieter-Kompos wie z.B. Styles von Devexpress u.ä. die schnell mal entstehen wenn man unbedacht auf eins dieser "Neues [xyz] erstellen" im OI oder Formulardesigner-Kontextmenü klickt. Die betreffende Komponente erscheint dann irgendwo im ohnehin unübersichtlichen Gewölle von Komponenten und wird vergessen. Nicht jede gut gemeinte Komfortfunktion ist auch wirklich sinnvoll...

Zitat:

Zitat von Uwe Raabe (Beitrag 1426431)

Zitat:

Zitat von Codehunter (Beitrag 1426429)

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

Deswegen ja auch dieser Hinweis:

Zitat:

Zitat von Uwe Raabe (Beitrag 1426425)

und dazu passend auch einen inversen Property Value Report

Schau ich mir zu ruhiger Stunde genauer an. Vielleicht ist ja was für mich.

[MyRealName]

Muss man aber vorsichtig sein, denn es kann auch sein, dass eine Komponente von aussen verlinkt wird, nicht nur im Quelltext der eigentlichen Unit.
Da müsste man nicht nur schauen, wo die Unit verwendet wird, dondern auch mit welchem Instanznamen das geschieht.

Bsp.:

in der Originalunit :

Code:

var
  MyDataModule: TMyDataModule;

in einer anderen unit :

Code:

uses 
  dmMyDataModule;

begin
  MyDM := TMyDataModule.Create(nil);
  MyDM.ObscureComponent.ExecuteStrangeThings;
  MyDM.Free;
end;

[jaenicke]

Noch fieser ist es, wenn eine Komponente nur dadurch verwendet wird, dass sie auf dem Formular bzw. Datenmodul liegt, sprich dass wie z.B. bei einigen Webkomponenten einfach alle Komponenten nach einem bestimmten Typ durchsucht werden.

Zitat:

Zitat von Codehunter (Beitrag 1426433)

Bekannte Beispiele, ja. In meinem Fall sind es weniger bekannte Drittanbieter-Kompos wie z.B. Styles von Devexpress u.ä. die schnell mal entstehen wenn man unbedacht auf eins dieser "Neues [xyz] erstellen" im OI oder Formulardesigner-Kontextmenü klickt. Die betreffende Komponente erscheint dann irgendwo im ohnehin unübersichtlichen Gewölle von Komponenten und wird vergessen.

Deshalb würde ich auch niemals Quelltext einchecken ohne diesen vorher genau zu überprüfen, sprich ich schaue mir jede geänderte Zeile an und prüfe, ob diese auch so gewollt war und zu der einzucheckenden Änderung gehört. Und das mache ich natürlich auch bei .dfm oder .dproj Dateien.

Ich sehe leider oft, dass einige das nicht machen und einfach einchecken nachdem eine Änderung kurz getestet wurde. Das ist finde ich ähnlich fahrlässig wie beim Auto auf Gehör zu fahren.