Unit-Abhängigkeiten visualisieren

[grizzly]

Nachtrag vom 21.03.2008
Habe vorige Woche festgestellt, daß UnitUsage 0.5 mit den allerneusten DOT Versionen nicht mehr richtig zusammenarbeitet. DOT.exe hat scheinbar das Format seiner temporären Ausgabe-Dateien leicht verändert.
Ich habe deswegen mal einen kleinen Hot-Fix gebastelt.

Leider bin ich noch nicht dazugekommen, alle von Gruber_Hans_12345 vorgeschlagenen Änderungen aufzunehmen. Somit bringt die 0.6 nur folgende neue Features:
- Läuft mit der momentan aktuellen DOT.exe
- WMF-Export und Drucken leicht verbessert (Die alte Version verschluckte manchmal Linien am Rand)
- Hervorhebung von Units deren Source-Code neuer ist als ein vorgegebenes Datum
- Einige Kleinigkeiten auf der Oberfläche (vermutlich mit neuen Bugs)

Source und binaries wie üblich hier: UnitUsage. (Hier gibt es auch noch die alte 0.5)

und im Anhang.


---- Ursprünglicher ursprünglicher Text --------------------------------------
Nachtrag vom 12.03.2007
UnitUsage ist nun bei Version 0.5 angelangt. Ein paar kleine Verbesserungen hat es gegeben (aber leider nichts weltbewegendes).
Binaries, Screenshot und Kurzbeschreibung gibt es nach wie vor hier im Anhang. Sourcecode (in seiner ursprünglichen Häßlichkeit) gibt's auf der zugehörigen Webseite von UnitUsage.

---- Ursprünglicher Text (Links erneuert) --------------------------------------
Erst kürzlich gab es einen Thread mit einem Programm zur Visualisierung von Unit-Abhängigkeiten unter Zuhilfenahme von GraphViz.
Genau soetwas hatte ich vor längerer Zeit auch schon begonnen und dann in meiner Firma ein wenig weitergepflegt.
UnitUsage ist nicht perfekt. Es kann auch nicht analysieren, welche Units gar nicht verwendet werden (da gibt es eh schon genug Tools dafür).
Die Stärke von UnitUsage ist das bequeme Browsen mittels Maus-Klick innerhalb der Unit-Verknüpfungen:

Screenshot siehe Anhang

Ich stelle UnitUsage mal hier in der Freeware-Abteilung vor, werde es aber Open-Source machen, sobald ich den Source-Code soweit aufgeräumt habe, daß ich mich nicht mehr allzusehr genieren muß ;)

Eine notdürftige Bedienungsanleitung findet sich hier: PDF 400KB (Die hat's bitter nötig, weil das User-Interface ist ein wenig sonderbar)

Unit-Usage 0.5 gibt es gezippt hier: ZIP 430KB
(Verwenden auf eigene Gefahr. Braucht's hier einen Disclaimer?)

Bei der Code-Analyse berücksichtigt UnitUsage zwar Compiler-Direktiven und Switches (auch so Zeug wie $ifopt etc...), liest auch Include-Dateien, kommt aber mit einigen neuen Konstrukten (Wie z.B. {$IF...} ) nicht zurecht. Units mit solchen Compiler-Direktiven werden dann ohne "Child"-Units angezeigt.

Nicht vergessen: Um UnitUsage zu verwenden benötigt ihr dot.exe von www.graphviz.org. Das ist das Teil, was den Löwenanteil der Arbeit übernimmt.

Gruß
Michael

[edit=sakura] Der ScreenShot reicht als Anhang und muss nicht gleichzeitig im Text gepostet werden. Mfg, sakura[/edit]

[fkerber]

Hi!

Eine Bitte an dich:
Auch wenn du im Titel auf den Screenshot hinweist, wäre es schön, wenn er stattdessen als Anhang erscheinen würde.
Dies würde v.a. auch sicherstellen, dass das Bild erhalten bleibt, wenn der externe Server mal nicht mehr erreichbar ist!

Danke! :thumb:


Ciao Frederic

[semo]

frage nebenbei:

Zitat:

Es kann auch nicht analysieren, welche Units gar nicht verwendet werden (da gibt es eh schon genug Tools dafür).

welche sind das?

[Bernhard Geyer]

Icarus

[grizzly]

@computer-glossar.de
Ich nehme zur Analyse der unbenutzen Units ganz gerne OPXPerts.

@Frederick
Ich hatte mich schon immer gefragt, wie die Leute immer diese Tabellen mit den Links einbauen. Danke für den Hinweis mit den Anhängen. Das mit den Attachments ist mir jetzt erst aufgefallen (Peinlich). Nächstes mal mach ich's besser!

Gruß
Michael

[fkerber]

Hi!

Zitat:

Zitat von grizzly

@Frederick
Ich hatte mich schon immer gefragt, wie die Leute immer diese Tabellen mit den Links einbauen. Danke für den Hinweis mit den Anhängen. Das mit den Attachments ist mir jetzt erst aufgefallen (Peinlich). Nächstes mal mach ich's besser!

Kein Problem! Aber du kannst es auch bei diesem Beitrag noch verbessern:
Einfach oben rechts am ersten Eintrag auf Edit klicken und dann das Bild anhängen!


Ciao Frederic

[MaBuSE]

Zitat:

Zitat von grizzly

Erst kürzlich gab es einen Thread mit einem Programm zur Visualisierung von Unit-Abhängigkeiten unter Zuhilfenahme von GraphViz.

Stimmt :-) der ist von mir.
Hättest Du Dein Programm ein paar Wochen früher gepostet, hätte ich mir zwei, drei Stunden Programmierung sparen können :-)

Sieht schön aus, Dein Programm. Kannst du das Programm auch als Attachment anhängen.
(Den 1. Beitrag einfach mit dem [Edit] Button bearbeiten)

Ich kann zwar auf delphipraxis zugreifen, aber nicht auf Deine Seite. (Firewall)

Danke.

Von meinem Programm habe ich gestern auch eine neue Version gepostet. ;-)
Beitrag: "Freware: Programm zur Ermittlung von Unit-Abhängigkeiten"

[grizzly]

Wunsch erfüllt. Ich habe die Dateien der drei Links im ersten Eintrag zusätzlich gepostet.

Boah, eine Firewall, die den Zugriff auf meine Seiten verbietet. Ein echter Verlust ;)

Gruß
Michael

[MaBuSE]

Zitat:

Zitat von grizzly

Boah, eine Firewall, die den Zugriff auf meine Seiten verbietet. Ein echter Verlust ;)

Deine Seite kann ich anschauen, nur nix downladen.

Das Programm gefällt mir sehr gut.

Die Idee den einzelnen Pfeilen eine eigene Farbe zu geben, um diese dann mit Hilfe der Farbenpalette schwarz bzw. rot / grün zu färben ist eine gute Idee :mrgreen:

Welche Komponente zum anzeigen der Grafik verwendest Du denn ?
Bestimmt nicht TImage von Delphi, oder?

Der Export nach wmf funktioniert gut, aber bei dem obersten Kasten wird die obere Linie abgeschnitten.
Der Export nach emf funktioniert bei mir nicht. Es wird keine Datei angelegt.

Der Export nach jpg funktioniert. Es wird dann die aktuelle vergrößerung exportiert.
(also vorher F12 drücken um 100% zu erhalten :-) )

Mit Rechtsklick auf Unit in Grafik kann man einen Parent der Unit als Ausgangspunkt festlegen um die Sichtweise einzuschränken. Es ist dann auch die Bottom Up Sichtweise möglich.
Leider ist es mir nicht möglich eine Unit die keine "Kinder" hat, als Ausgangspunkt festzulegen, so das man z.B. sehen könnte welche Units in dem Projekt alles diese Biliothek verwenden. (z.B. Variants.pas)
(Nachtrag: Es ist doch möglich, aber Umständlich. Auswahl des Parrent -> neuer Graph -> auf Bottom Up umschalten ->Parent rechtsklicken und gewünschte Unit auswählen. (evtl. noch auf mit Kindern umschalten) Das ist sehr Umständlich. Besser wäre es die gewünscht Unit diekt auszuwählen und nicht den parrent)

Ich würde auch gerne die Möglichkeit haben den Text des dot Skriptes zu sehen / ändern.
(Dann könnte man sich den Umweg über die temp.dot sparen.)
Ich finde es z.B. nützlich verschiedene Units in logischen Gruppen zusammenzufassen (Cluster)

Die Unterscheidung zw. Unit ohne dfm (beige) und unit mit dfm (mintgrün) finde ich auch gut.
Genauso wie die Unterscheidung zw. mit Kindern (Rechteck) und ohne Kinder (Oval).

Also alles in allem super Programm !!!

btw: Wie viel Zeit hast Du in das Programm investiert?

[MaBuSE]

Ich habe noch was gefunden:

Dein Parsing der Units funktioniert nicht 100% richtig.

Folgendes Beispiel kannst du zu hause selbst testen ;-)

Erstelle eine neue Anwendung.
(Project1.dpr, Unit1.pas und Unit1.dfm)

Diese jungfräuliche Anwendung speicherst Du in einem leerem Order.
Dann kopierst Du die Quellcodedateien der VCL in das selbe Verzeichnis.
( wenn $(DELPHI) = C:\Programme\Borland\Delphi7, dann kopiere $(DELPHI)\Source\Rtl\Common, $(DELPHI)\Source\Rtl\Sys und $(DELPHI)\Source\Rtl\Win, $(DELPHI)\Source\Vcl )

Damit kannst Du dann alle Abhängigkeiten einer einfachen Anwendung inkl VCL zeigen.


(Bild anklicken um die 1027x768 Version zu sehen)
(siehe auch: http://www.delphipraxis.net/internal...=557810#557810 )

In Deinem UnitUsage werden aber auch folgende Artefakte als Units angezeigt:
"{$ENDIF}", "{$ifdef", "and", "case", "directories)", "directory", "etc.)", "file", "it", "Libc", "Ipici->IpVerb", "NMMOUSE", "server", "StdActns{$IFDEF", "SwitchChars", "that", "the", "then", "this", "Types{$IFDEF", "which", "which member function to invoke a command programmaticly. The explorer displays the help text in his status bar", "WinHelpViewer{$ENDIF}", "work-goup"

Siehe auch Screenshot im Anhang.

Bei Libc, server, SwitchChars könnte ich mir ja noch Units vorstellen, aber nicht bei den Namen, die z.B. Zeichen beinhalten, die bei Units verboten sind. <> ['a'..'z', 'A'..'Z', '_', '0', '1'..9']

Du solltest Dir das fehlerhafte Verhalten mal anschauen.

[grizzly]

Danke für den intensiven Test! Das ist ja in der Tat ein sonderbares Verhalten.
Vielleicht habe ich aus unserem Firmentool vor Freigabe als "Freeware" doch zu viel rausgeschnitten (ich mußte einige firmeninterne Konstrukte und Analysen ausbauen).
Leider kann ich mir das erst heute abend ansehen.
Diese Parserei...

Dank und Gruß
Michael

[grizzly]

Zitat:

Welche Komponente zum anzeigen der Grafik verwendest Du denn ?
Bestimmt nicht TImage von Delphi, oder?

Doch. Ganz zu Anfang konnte man ja noch nicht im Graphen rumklicken und browsen. Da war das das bequemste, und es läuft ja noch immer...

Ich veranlasse dot.exe ja nicht ein JPEG oder ein GIF oder so etwas auszugeben. Ich verwende den Parameter -Tplain-ext. Die Datei temp.txt, die dabei erzeugt wird, beinhaltet alle Infos die ich brauche, um den Graphen selber zu zeichnen (Somit habe ich keine Probleme mit dem Skalieren oder dem Export als Vektor-Grafik). Gezeichnet wird natürlich auf ein separates Bitmap, welches nach fertigstellung ins Image kopiert wird.

Das mit dem selber-zeichnen ging auch nur, nachdem ich entdeckt habe, daß ich die zig Koordinaten, welche für die krummen Pfeile ausgegeben werden, mittels Canvas.PolyBezier identisch wie dot.exe ausgeben kann.


So, nu muß ich zurück an die Arbeit.
Bug-Hunting heute abend...

Gruß
Michael

[MaBuSE]

Zitat:

Zitat von grizzly

Bug-Hunting heute abend...

Und? Was gefunden?
:coder:

[grizzly]

Leider noch nicht, durfte bis kurz vor 23:00 bei 31° im Büro Überstunden schieben. Im Office mal wieder Hektik, Deadlines etc. Aber das kennt ihr ja alle ;)

Montag abend sollte ich hoffentlich dazu kommen.


Gruß
Michael

[grizzly]

So, nun hatte ich Zeit mir das mal anzusehen...

Das Problem ist:
Um die Liste der verwendeten Units aus dem Code zu lesen, verwende ich ein kleines Stückchen Code, welches aus einem Pascal-Source sämtliche Kommentare, strings und toten Code (wg. Compiler-Direktiven) rauswirft. Was bleibt, ist purer reiner Pascal Code. Und wenn ich da drin ein "Uses" finde, dann ist es das ein "echtes" (und keines in strings, Kommentaren etc.).

Nun ist dieser Code-Teil etwas alt. Der hat beispielsweise Probleme mit {$IF ..} und anderem neumodischen Kram.
Und in einer der Delphi Units kommt im Assemblerteil ein string in folgendem Format vor: "'". Wußte bis letzte Woche gar nicht, daß man das im asm Teil machen darf.
(Habe gerade gesehen, daß im Browser das >> "'" << gar nicht richtig zu erkennen ist. Also, das ist: Gänsefüßchen, Apostroph, Gänsefüßchen)

Lange Rede, kurzer Sinn: Weil ich es in absehbarer Zeit eh nicht schaffe, auf all' diese Konstrukte Rücksicht zu nehmen, wird UnitUsage bis auf weiteres Source-Code, bei dem es Probleme gab, nur noch ohne "Child" Units anzeigen. Nicht toll, aber wenigstens nicht so falsch wie vorher;)
Einige simplere neue Direktiven werden aber nun abgefangen, es bleiben somit nicht mehr allzuviele unbehandelte Units übrig.

Die 0.43 liegt nun im ersten Eintrag zu diesem Thread zum Download bereit.

Zusätzlich neu ist die Möglichkeit der Angabe eines Suchpfades. (Dann braucht man sich die RTL nicht mehr mit in das Source-Verzeichnis kopieren).
Außerdem habe ich begonnen einen Viewer mit einzubauen, aber dieses verd... TRichEdit ist dermaßen träge, daß damit niemand sowas wie windows.pas aufmachen sollte. Das dauert Minuten, bis das angezeigt wird!


Gruß
Michael

[himitsu]

Zitat:

Zitat von grizzly

Und in einer der Delphi Units kommt im Assemblerteil ein string in folgendem Format vor: "'". Wußte bis letzte Woche gar nicht, daß man das im asm Teil machen darf.
(Habe gerade gesehen, daß im Browser das >> "'" << gar nicht richtig zu erkennen ist. Also, das ist: Gänsefüßchen, Apostroph, Gänsefüßchen)

Wenn du wüstest, was alles möglich ist :lol:

wenn ich mal die Gelegenheit finde, stell ich dir mal ein paar meiner Units zusammen ... ich gehe ja öfters mal "unortodoxe" Wege und daher ist der entstehende Code ... nun ja, sagen wir mal gut für Testzwecke :stupid:

ich glaub MaBuSE (oder von wem das andere Programm dieser Art ist) war von sowas wie dem hier dodal geschockt und wunderte sich, dat dieses wirklich läuft.

Delphi-Quellcode:

Unit TestU;

Interface       
  {$INCLUDE FNS_VersionsCheck.inc}

  Uses Classes, Controls, Forms, StdCtrls, ExtCtrls, Math, PSAPI, Windows, SysUtils,

    FNS_Consts, FNS_Types, FNS_Memory, FNS_System,
    FNS_Messages, FNS_Languages, FNS_Forms,
    FNS_MathB, FNS_Log,

    FNS_Binary{, FNS_Colors{, FNS_DateTime}, FNS_Debug{, FNS_Files{, FNS_Hash{, FNS_Hints}, FNS_MemoryUT{, FNS_MemoryUT2}, FNS_Security, FNS_Strings{, FNS_Sys}, FNS_Unicode{,
    MSC_WinError}, FNS_ValueConvert, FNS_Thread{, FNS_SpeedZip{, FNS_XPStyle};

Mehrfach verschachtelte Kommentare sind echt witzig.
Und soein {$INCLUDE ...} an den unpassensten Stellen kommt bestimmt och geil. :roll:

[MaBuSE]

Zitat:

Zitat von himitsu

ich glaub MaBuSE (oder von wem das andere Programm dieser Art ist) war von sowas wie dem hier dodal geschockt und wunderte sich, dat dieses wirklich läuft.

Mich schockt nix mehr :-)

Das das läuft war mir klar, das es Programmier gibt, die so was auch wirklich machen, nicht :shock:

[himitsu]

Hey, dat is aus 'nem Testprogramm und da ändert sich ständig was an der Unitzusammenstellen (selbst die Prozeduren/Funktionen in dem Programm leben manchmal nichtmal 'ne Stunde lang) und da hab ich halt keine Lust ständig die Unitnamen neu einzugeben, sondern kommentiere halt Nichtbenötigtes aus.

Die Verschachtelung von { } und (* *) is och genial, wenn man mal kurzzeitig mehr, oder weniger radikal Code loswerden muß ._.

Und wie schön man speichersparend die selbe lokale Variable rekursiv in mehreren Prozeduren verwenden kann, könntest du dir ja hier ansehen.
> GetVolumePathNamesForVolume > speziell ResultBuffer :roll:

[grizzly]

Jaja, künstlerisch verstrickter Code zeigt die Schwächen der Parser am schnellsten. Wobei UnitUsage leider noch weit davon entfernt ist, sich nur noch an heimtückischen Codeteilchen zu verschlucken.
Ich denke allerdings, daß die verschachtelten Kommentare und das {$include ..} von UnitUsage mittlerweile ohne Schluckauf verdaut werden sollten. Aber ich hab' schon öfters geträumt, daß irgendwas eigentlich funktionieren sollte...

Die nächsten zwei Wochen werde ich nicht dazu kommen, UnitUsage aufzurüsten. Aber wenn ich dann mal den Parser etwas besser durchtrainiert habe, teste ich ihn gern an "unorthodoxen" Code-Beispielen ;)

Ob der Parser die Kommentare und die per conditional defines trocken gelegten Code Teile richtig erkannt hat, sieht man in UnitUsage mittlerweile über das View-Kommando (Rechter Mausklick auf Unit, egal ob Graph oder Liste). Solcher Text wird ausgegraut (cond. defines) oder blau/kursiv (Kommentare) dargestellt. Doch wie schon oben erwähnt: Blos keine großen Source-Codes damit ansehen. TRichEdit lädt sich zu Tode...


Gruß
Michael

[Gruber_Hans_12345]

also wirklich genial das teil, wäre cool, wenn du das mal opensource machen würdest ;)

• Wenn der Parser an ein File kommt, das ein anderer Prozess sperrt, zeigt er dieses zwar richtig an, aber nachher lässt sich auf der Oberfläche nichts mehr bedienen, und man muß den Prozess rauswerfen
• ein zoom und so wäre für den Graph ganz nett, man kann zwar exportieren, aber da kann man dann nicht so schön suchen ...
• da das erzeugen des graphen bei vielen units teils extrem lange dauert, wäre es vielleicht ne option, zuerst mal alle Units deselektieren, dann wenn man im tree eine unit selektiert, sollte in der Statusleiste auch die Infos angezeigt werden (genau so wie wenn man die unit im graphen selektiert)
• ich verwende in {$I DEFAULT.INC} und dieses Default.inc enthält nur eine einzige {$DEFINE DEBUG} ... die Sources was diese DEfault.inc einbinden kann er nicht parsen (ExceptionHandling.pas parsing error: " ExceptionHandling.pas Line 3: Unexpected end of file in comment started on line 4")

[grizzly]

UnitUsage OpenSource zu machen war von Anfang an meine Absicht. Allerdings wollte ich das in der momentanen Verfassung des Source-Codes nicht tun, viel zu peinlich. Ich habe sogar schon angefangen, den Code zu überarbeiten, muß allerdings gestehen, daß ich mangels Zeit noch nicht weit gekommen bin, und zu allem Überfluß das Programm in der neuen Form gar nicht mehr richtig funktioniert. (Oh Gott, hab ich noch mein altes Archiv?) Also eigentlich müßte ich es von Grund auf neu schreiben, korrigieren hilft da schon gar nicht mehr.

Lange Rede, kurzer Sinn: Ich habe gestern beschlossen, UnitUsage demnächst in der ursprünglichen Grusel-Form freizugeben. Nur noch sauber einpacken ;)
(Aber man darf mich gerne wieder dran erinnern, falls sich in drei Wochen immer noch nichts getan hat...)

Gruß
Michael

[Gruber_Hans_12345]

hi grizzly,

sind zwar noch keine 3 wochen vorbei, aber frage trotzdem schon mal nach ;)

[grizzly]

Ich habe mittlerweile meinen alten Source-Code Stand vor meinen Aufräum-Aktionen ausgegraben (uff!) und bin schon dabei, die schlimmsten Sachen auszumerzen. Bei den Sachen, die ich noch kapiere, schreib ich auch noch ein wenig Kommentar rein.
Richtig Aufräumen schaffe ich leider nicht. Design und Architektur lassen sich halt nicht nachträglich einbauen ;)

Es sollte also klappen, die drei Wochen werde ich vermutlich nur knapp verfehlen. Noch'n bissl Geduld. Gut Ding will Weile haben. Und UnitUsage auch....

Gruß
Michael

[Gruber_Hans_12345]

*push*

Zitat:

Zitat von grizzly

(Aber man darf mich gerne wieder dran erinnern, falls sich in drei Wochen immer noch nichts getan hat...)

;)

[grizzly]

Timeline nur knapp gerissen. Version 0.5 ist "fertig". Siehe ersten Eintrag dieses Threads.

Gruß
Michael

[Gruber_Hans_12345]

perfekt danke super :)

hab auch gleich mal 3 kleine änderungen ...


Änderung 1 :

Delphi-Quellcode:

DelDirective (Zeile 1262)
                        IF KnownDirective('I') or KnownDirective('INCLUDE') THEN { Include files }
                            Result := ProcessInclude(ActiveCDirPara); // Recursive call!

Habe diese zwei zeilen in die (IF CompDirValid then) gesetzt, da sonst auch $I berücksichtigt werden, die eigentlich nicht sollten


Änderung 2

Delphi-Quellcode:

DelDirective (Zeile 955)
                        (Long:'HINTS';          Short:' '),
                        (Long:'STACKCHECKS';    Short:' '),

HINTS und STACKCHECKS hinzugefügt zum array Directive


Änderung 3

Delphi-Quellcode:

DelDirective (Zeile 1239)
                             IF not b THEN
                               BEGIN
                                 b := DefList.Find(InvertCompDir(#1+ActiveCDirPara), i);  // Check, if inverted compiler directive is known
                                 (*
                                 IF not b then
                                   begin
                                     Result := -4;
                                     CreateErrorMsg(ErrMsg, SourceFileName, Row, 'Compiler switch '+ copy(ActiveCDirPara, 1, Length(ActiveCDirPara)-1) + ' not specified');
                                   end;
                                   *)
                               END;

Hab das not mal auskommentiert, warum muß die compilerdirektive als - da sein ?
wenn ich schreibe {$IFOPT C+} und C+ nicht gefunden wurde, dann ist die IFOPT ungültig und sollte nicht geparst werden oder ? (und es muß keine C- gesetzt sein oder?


so, mein erstes projekt kann er jetzt mal ohne probs parsen, mal mein großes testen ...


hab auch mal die zwei units (für BuildGraph) mit einer cache liste beshcleunigt, da die bei mir extrem oft aufgerufen werden ... allerdings ist das dot.exe so langsam, das ich es beim großen projekt nicht erwarten kann das es fertig wird ... (die temp.dot datei hat 4600 zeilen ...)

Delphi-Quellcode:

procedure TForm_Main.BuildUnitCache;
var
    i       : integer;
begin
    unitCache   := TStringList.Create;
    unitCache.CaseSensitive := false;
    for i:=0 to CheckListBox_Units.Count-1 do
        if CheckListBox_Units.State[i] IN [cbChecked, cbGrayed] then
            unitCache.AddObject(UpperCase(CheckListBox_Units.Items[i]), TObject(CheckListBox_Units.State[i]));

    unitCache.Sorted    := TRUE;
end;

FUNCTION TForm_Main.UnitInGraph(UnitName: string): boolean;
{ - Unit is patr of the graph? }
VAR
  i : integer;
BEGIN
  Result := false;
  if unitCache = nil then BuildUnitCache;

  Result    := unitCache.IndexOf(UnitName) >= 0;
END;

FUNCTION TForm_Main.UnitShowChilds(UnitName: string): boolean;
{ Show child Units for that Unit? Depends on user setting and result of code analysis ) }
VAR
  i : integer;
BEGIN
    Result := false;
    if unitCache = nil then BuildUnitCache;
    i   := unitCache.IndexOf(unitName);
    if i >= 0 then
        Result  := TCheckBoxState(unitCache.Objects[i]) in [cbChecked];
END;

also dot.exe dauert nur ca. 30 minuten, dann ist es fertig ...
und das bild sieht wirklich lustig aus (ob man da noch was erkennen kann? ;) )

[grizzly]

Hui, da regnets aber Vorschläge und Verbesserungen. Super :)
Leider kann ich mir das erst heute abend richtig ansehen.
Aber eines interessiert mich doch jetzt schon: 4600 Zeilen im temp.dot? Das bedeutet ja gut 4000 Pfeilchen in der Grafik! Was ist das für ein Projekt? Wieviele Units hängen denn da drin? Das schafft ja kaum die komplette VCL, oder?

Gruß und Danke für die Änderungsvorschläge
Michael

(Wird wohl bald ein 0.51 geben müssen...)

[Gruber_Hans_12345]

ja müssten so 2000 units sein ...
mit (fast) allen komponenten im search path komme ich dann auf eine dot datei mit 26500 zeilen, aber die will ich dem nicht mehr berechnen/zeichnen lassen ;)

aber ich brauche das tool hauptsächlich für die kleinen nebenprojekte zum analysieren welche units (bzw. warum diese drinnen sind) und dafür ist es schon fast ganz perfekt ;)

[grizzly]

Ha, das Bildchen (3 Einträge weiter oben) kenn' ich doch! So sehen bei mir auch manche Projekte aus;)
(Leider zeigt sich da auch schon wieder ein Bug: Die Schriftart ist zu groß :( )
Hatte mir auch schon überlegt, ob ich für solche Projekte nicht noch einen Poster-Druck in das Programm einbauen sollte. Macht sich einfach toll an der Bürowand. Damit die Kollegen mal wissen, wogegen man ankämpft....

Gruß
Michael

[Gruber_Hans_12345]

wollte es mal probieren, als WMF exportieren, und dann ins coreldraw rein, das hat ja nen posterdruck

allerdings macht das dot bei den pfeilen ein paar fehler, (sieht zumindest so aus) da gibts ein paar pfeile ohne linien ... leider hab ich das wmf nicht mehr, werds bei gelegenheit noch mal neu machen, und reinzoomen

[MaBuSE]

Zitat:

Zitat von Gruber_Hans_12345

wollte es mal probieren, als WMF exportieren, und dann ins coreldraw rein, das hat ja nen posterdruck

allerdings macht das dot bei den pfeilen ein paar fehler, (sieht zumindest so aus) da gibts ein paar pfeile ohne linien ... leider hab ich das wmf nicht mehr, werds bei gelegenheit noch mal neu machen, und reinzoomen

Du kannst auch in der *.dot Datei die Auflösung (size="10" -> 10 inches) und das Seitenverhältnis (ratio="0.7")ändern.
[edit]Was vorallem bei jpg & co interesant ist. Aber auch bei Vektorgrafik wird die Schrift kleiner je größer das size ist.[/edit]

Code:

DiGraph Uses {
  graph [ratio="0.7"];
  node [label="unit dependencies for Project1.dpr"];
  "Project1.dpr" [shape=box, style=filled, color=red]
  "Project1.dpr" -> "Unit1.pas";
  "Project1.dpr" -> "Unit2.pas";
...
}

Siehe Handbuch (Anhang Tabelle 3 auf Seite 13 "graph attributes")

Viel Spaß

[grizzly]

Zitat:

Zitat von Gruber_Hans_12345

...allerdings macht das dot bei den pfeilen ein paar fehler, (sieht zumindest so aus) da gibts ein paar pfeile ohne linien ...

Da muß ich dot.exe jetzt in Schutz nehmen. Die angezeigte Grafik wird ja gar nicht von Dot.exe gezeichnet. Das mache ich innerhalb UnitUsage ja selber. Vermutlich ist das das Problem. Man könnte sich natürlich in DotGlob.pas beim Aufruf von Dot (In Prozedur RunDot, ca. Zeile 567) auch gleich eine Vektorgrafik mit ausgeben lassen (z.B. mit -Tsvg), dann sähe man ja, wo der Hund begraben ist.

Gruß
Michael

[Gruber_Hans_12345]

das meine ich mit falschen pfeilchen, (ist als WMF exportiert und im coreldraw dann vergrößert)

im unitusage kann man nicht so stark vergrößern, nachdem es 1GB RAM verbraten hat, kommt dann out of system ressource ;) (obwohl, der rechner hätte noch ein paar reserven .... )

[grizzly]

So hatte ich das ja auch verstanden.

Was ich meinte war: Wenn dot.exe das Bild selbst gemalt hätte, dann wären die Pfeile vermutlich richtig gewesen. Dot.exe kann ja auch Bilder und Vektorgrafiken ausgeben. Das nutze ich in UnitUsage aber nicht. Ich rufe dot.exe mit dem Parameter Tplain-ext auf und erhalte damit eine Datei mit Informationen, wie ich das Bildchen zu zeichnen habe. Die Angaben zu den Pfeilen bestehen aus einer Liste von Punkten, die sich glücklicherweise mit dem Befehl Canvas.PolyBezier(...) identisch zu den von DOT selbst erzeugten Bildern zeichnen lassen. Den Kopf der Pfeilchen muß ich mir aber selbst errechnen (TDot.CalcArrowEdges). Vielleicht hab' ich da ja noch irgendwo einen Fehler. Kann natürlich sein, daß es durchaus auch schon von DOT falsch berechnet wird. In der Regel bin aber immer ich schuld.

Ein WMF Export in UnitUsage exportiert immer nur meine "Interpretation" der DOT Grafik. Eine unangetastete, original unverfälschte DOT Grafik erhielte man eben über einen zusätzlichen Parameter (wie beispielsweise das erwähnte -Tsvg).

1GB verbraten? Nicht schlecht. Vielleicht sollte ich wenigstens von pf24bit auf pf8bit runterschrauben...

Gruß
Michael

[Gruber_Hans_12345]

hi grizzly,

wollte mal kurz nachfragen, ob du noch verbesserungen brauchst ...

hab noch eines beim RTF export
DelDirective.pas / 891

Delphi-Quellcode:

        FUNCTION ProcessInclude(FileName: string): integer;
        { Handles recursive procedure call to process an include file }
        BEGIN
          Result := -1;
          if ExtractFileExt(FileName) = '' then
            ChangeFileExt(FileName, '.pas');
          FileName := FileSearch(FileName, SearchPath);
          IF FileName = '' then
            EXIT;
          Result := RemoveDeadCodeEx(FileName, SourceFileName, Row, SLOriginal, SLProcessed, [b]SLSourceRTF[/b], SLRoutines, ParseAction, SearchPath, DefList, ErrMsg); << SLSourceRTF
        END; {ProcessInclude}

und hab auch noch (zwar ein etwas Quick and Dirty reingebaut (aber habs auf die schnelle gebraucht und funkt auch) das er bei den uses im projekt Source file die in erkennt und das richtige file lädt (beim alten hat er IMMER im Search Pfad gesucht) .. sind aber ein paar kleinere Änderungen an verschiedene Stellen ...

[grizzly]

Aber immer gerne!
Das mit dem IN war eines der nächsten Dinge, die ich eigentlich anpacken wollte, allerdings haben mich wieder tausend andere Dinge aufgehalten. Auch gut, wenn's schon fertig ist. :-D Das mit dem Quick-und-Dirty ist bei meinem restlichen Code schließlich auch kein Problem.
Bei nächster Gelegenheit werde ich Deine Änderungen und Erweiterungen mit einbauen.
In knapp zwei Wochen sollte ich dafür mal wieder Luft haben...

Grüße
Michael

[grizzly]

Habe soeben die Version 0.6 im ersten Eintrag dieses Threads verlinkt. Update war nötig, weil das alte UnitUsage mit den neuesten DOT Versionen nicht mehr zurecht kam.
Die von Gruber_Hans_12345 vorgeschlagenen Änderungen sind allerdings noch nicht drin (Ich hab' das Tool bis vor kurzem nicht mehr benötigt und deshalb nicht mehr dran rumgeschraubt.)
Sourcecode ist auch nicht aufgeräumt, umstrukturiert oder sonstwie überarbeitet. Ist halt "as is", entstanden aus einer Experimentier-Laune heraus ;)


Gruß
Michael

[himitsu]

Das mit dem IN hab ich auch grad gemerkt, als einige Dateien nicht geladen wurden

Und dann gab's noch andere Probleme:

Zitat:

Demo_Tree.dpr parsed.
himXMLi.pas parsing error: " himXMLi.pas Line 18: Unknown compiler directive REGION
himXMLi.pas Line 18: Unexpected end of file in comment started on line 19"
himXML.pas parsing error: " himXML.pas Line 18: Unknown compiler directive REGION
himXML.pas Line 18: Unexpected end of file in comment started on line 19"
Demo_TreeU.pas parsed.
Time: 0,0sec.
Error parsing 2 file(s). No "child" units will be displayed for these units.

und ich rechne mal Stark, daß dieses $REGION nocht das kleinste Problem sein wird.

Ich weiß, meine Units sind ein Kraus für derartige Verarbeitungen. :oops:

Die vordefinierten Compilerschalter gehen nur bis D7 und es wäre kein Problem die Fehlenden selber anzugeben oder eben noch nachzurüsten, nur leider gibt es ja größere Problemchen. :?



Eigentlich wollte ich nur mal sehen, in wie weit sich etwas anderes Nachrüsten läßt...

Auf den Delphi-Tagen kam unter Anderem die Frage wieder auf,
nach einer "optimaleren" Unit-Reinfolge, damit das Projekt eventuell schneller kompiliert werden würde.
Und da dacht ich mir, warum nicht gleich einen "feritgen" Parser ausnutzen, bzw. es gleich hier mit einbauen und nur noch das Ergebnis durchzugehn. :nerd:


Na gut, da der Aufwand nun größer werden dürfte, werd' ich das erstmal rausschieben und andere Dinge fertigmachen.

Als Test hatte ich himXML > demos > Demo_Tree.dpr verwendet, falls es wen interessiert.



[add]
was ich mich grad fragte: Man kann doch in die IDE irgendwie Zusatzmodule integrieren und daraus auf die "aktiven" Dokumente zugreifen.
Gäbe es da eine Möglichkeit direkt den delphieigenen Parser zu nutzen und darüber direkt die Units abzufragen?

[grizzly]

Richtig, wenn man REGION und ENDREGION nachrüstet (Unit DelDirective.pas, SkipMinorCompilerDirectives), dann ist man nicht viel weiter: Des Pudels Kern ist {$IF . Da müßte ich beginnen, den folgenden Bedingungen auszuwerten und abzuprüfen etc. Das war mir dann doch zuviel (und bei meinen Projekten benötige es (noch) nicht.). Mein Ansatz des "Parsens" war derart primitiv, daß sich diese Auswertung nicht bequem drauf aufsetzen läßt.

Sorry
Michael

[add] Dafür den Delphi-eigenen Parser nehmen zu können wär ein Traum. Aber davon versteh' ich leider noch weniger...

[omata]

klick