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

[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?

[Codehunter]

Zitat von 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?

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 von 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

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 von Codehunter:

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.

[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