![]() |
AW: Cnpack Unit-Cleaner
---
|
AW: Cnpack Unit-Cleaner
@nahpets
Bei D7 ging das finden von Units m.E. noch zuverlässiger (dass die IDE fehlende immer ergänzt ist mir aber gerade neu - nur bei Ctrl+F9 oder auch bei F9?). Mit XE3 nicht mehr. Da gibt es Ctrl+Shift+A zum Finden einer Unit, die eine bestimmte Klasse implementiert. Meist funktioniert das auch nicht. Dann suche ich die Klasse oder Funktion in der Hilfe und hoffe, dort etwas zu finden oder ich suche die Klasse bzw. Funktion in im Projekt (wenn sie schon mal verwendet ist) und springe dann mit Ctrl+Click zur Deklaration. Delphi-IDE halt... |
AW: Cnpack Unit-Cleaner
Das wäre dann aber ein massiver Rückschritt.
Eigentlich mache ich mir über die genutzten Units nie Gedanken. Zu allem, was ich so auf ein Formular pappe, wird von der IDE beim Kompilieren (egal ob F9 oder Ctrl+F9) alles Fehlende eingefügt. Habe ich im Quelltext irgendwelche Verweise auf andere Formulare, Datenmodule ..., die schon irgendwo im Projekt eingebunden sind, dann werde ich ggfls. gefragt, ob sie noch in eine Unit eingebunden werden sollen. Das passiert halt schonmal, wenn man aus Form1 auf Form2 verweist ... Was nie automatisch eingebunden wird sind StrUtils, Math ..., also die Units, die nur reine Funktionssammlungen sind. Grob kann man wohl sagen: Automatisch ergänzt wird alles, was über die in die IDE eingebundenen Packages irgendwie referenziert und genutzt wird. Mit Nachfrage wird eingebunden, was ins Projekt (die .dpr) eingebunden wurde. |
AW: Cnpack Unit-Cleaner
Zitat:
|
AW: Cnpack Unit-Cleaner
Deswegen meinte Glados, dass es wünschenswert wäre, dass die IDE auch Klassen und Funktionen findet, die nicht registrierte Komponenten in der Komponentenpalette sind.
|
AW: Cnpack Unit-Cleaner
@uligerhardt: Das war mir so noch nicht bewusst.
Bisserl nachdenk ... ja, Du hast recht. @stahli Ja, der Wunsch ist nachvollziehbar. Bei Sachen, die man nicht regelmäßig nutzt und deren Herkunft man nicht so genau kennt, kann man da schonmal etwas mehr Suchaufwand benötigen, bis man das Richtige gefunden und eingebunden hat. |
AW: Cnpack Unit-Cleaner
Zitat:
Die Dateien im initialization Teil zu löschen finde ich extrem gefährlich. Das es compiliert heißt nochlange nicht, dass auch alles noch so funktioniert. Wie Uwe schon schrieb: Zitat:
|
AW: Cnpack Unit-Cleaner
Zitat:
Zitat:
Und Units mit initialization und finalialization Teil habe ich etwa eine Hand voll. |
AW: Cnpack Unit-Cleaner
Zitat:
Beispiel:
Delphi-Quellcode:
unit A;
interface type TMyAbstractClass = class public procedure DoSomething; virtual; abstract; end; var MyInstance: TMyAbstractClass = nil; implementation end.
Delphi-Quellcode:
Unit B hat einen leeren interface-Teil, kann also nirgendwo zum compilieren gebraucht werden. Trotzdem funktioniert das Programm nicht, wenn Unit B nicht trotzdem irgendwo in der uses-Anweisung steht.
unit B;
interface implementation uses A; type TMyClass = class(TMyAbstractClass) public procedure DoSomething; override; end; procedure TMyClass.DoSomething; begin // mach irgendwas end; initialization MyInstance := TMyClass.Create; finalization MyInstance.Free; MyInstance := nil; end; |
AW: Cnpack Unit-Cleaner
Jetzt habe ich es auch verstanden.
Dann habe ich ja nochmal Glück gehabt denn ich kann 1. noch hinweis- und fehlerfrei kompilieren und 2. habe ich keine Zugriffsverletzungen oder ähnliches. |
Alle Zeitangaben in WEZ +1. Es ist jetzt 06:18 Uhr. |
Powered by vBulletin® Copyright ©2000 - 2025, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz