Gemeinsame Uses Klausel in allen Units

[fkerber]

Hi!

Ja, wenn das Include dann über der Stelle des Aufrufs steht und dazu an einer Stelle, wo auch dein Code-Ausschnitt stehen könnte, dann klappt das!


Ciao, Frederic

[Angel4585]

könnte man das so umbiegen das man die Datei erst zur Laufzeit angibt und der Code dann ausgeführt wird?

[mkinzler]

Nein, weil der Compiler ja den Inhalt der includierten Datei vor dem Compilieren an die Position einfügt.

[Angel4585]

Habs grad in der Hilfe gefunden:

Zitat:

Anmerkungen
Die Parameter-Direktive $I weist den Compiler an, die angegebene Datei in die Compilierung aufzunehmen. Diese Datei wird direkt nach der Direktive {$I Dateiname} in den Text eingefügt. Die vorgegebene Namenserweiterung für die Datei ist .pas. Wenn die Datei ohne Verzeichnispfad angegeben wird, sucht Delphi die Datei in dem Verzeichnis, in dem auch das Modul liegt. Außerdem werden alle Verzeichnisse durchsucht, die im Eingabefeld Suchpfad der Registerkarte Verzeichnisse/Bedingungen im Dialogfeld Projekt/Optionen (oder mit der Option -I in der dccil-Kommandozeile) festgelegt wurden.

Wenn der Dateiname ein Leerzeichen enthält, schließen Sie ihn in halbe Anführungszeichen ein: {$I 'Meine Datei'}.

Für die Verwendung von Include-Dateien gilt eine Einschränkung: Sie können nicht in einem Anweisungsblock eingebunden werden. Dies liegt daran, dass zwischen den Schlüsselwörtern begin und end alle Anweisungen eines Anweisungsblocks aus derselben Quelldatei stammen müssen.

[fkerber]

Hi!

Das geht, wie der Name sagt, mit diesen Compiler-Switches nicht!
Um zur Laufzeit noch Code einzubinden gibt es andere Mittel und Wege (die man auch im Forum finden kann).

Sollten da noch Fragen sein, aber am besten einen neuen Beitrag anfangen, da das hier ja schon nichts mehr mit dem Ausgangsthema zu tun hat


Ciao, Frederic

[Elvis]

Zitat von berens:

Gibt es also eine Möglichkeit, wie z.B. bei PHP (war das Include?) einfach an diese Stelle der Unit eine andere Datei hineinzuladen, wo z.B. alle Uses drinstehen?

Die Idee ist IMHO ziemlich krank.
Die einzige n 2 Stellen in denen includes sinn machen sind Stellen, die ein Defizit im Compiler selbst auszugleichen versuchen:

1. Compiler versionsprüfungen
   der Präprozessor kann (zumindest in D7) keine Ausdrücke á la {$ifdef compilerversion < 170}
2. Pseudo templates

Ich simuliere in native Delphi namespaces indem ich in einer Unit Aliases auf die Typen in den anderen Units aufliste. Auf die Art hat man seine Typen immer noch schön in einzelnen Units, aber braucht nur einen "Namespace" einzubinden um alle Typen benutzen zu können.
Bleistift (habe die Leerzeilen entfernt ):

Delphi-Quellcode:

unit uClass1;
interface
type
  Class1 = class
  end;

Delphi-Quellcode:

unit uClass2;
interface
type
  Class2 = class
  end;

Delphi-Quellcode:

unit MyClasses;
interface
uses
  uClass1,
  uClass2;
type
  Class1 = uClass1.Class1;
  Class2 = uClass2.Class2;

Delphi-Quellcode:

unit Babla;
interface
uses
  MyClasses;
type
  Class3 = class(Class2)
  end;

[dataspider]

Zitat von berens:

Hallo!

Ich versuche gerade bei meinem Projekt jede Komponente in eine eigene Unit zu machen.

Hi berens,

bei der ganzen Diskussion weise ich dennoch darauf hin, dass es keinen Sinn macht, jede Komponente in eine eigene Unit zu verfrachten. Man kann sich die Delphi VCL schon als Vorlage benutzen.
So sollte man seine Komponenten in logischen Einheiten zusammenfassen.
Ich benutze z.B. die Namenskonventionen von Delphi und setzt nur 2 Buchstaben davor.
So habe ich alle Controls in rwControls.pas, alles für die Datenbank in rwDB.pas und allgemeine Routinen in rwSysUtils, Formularklassen und Routinen in rwForms etc.
Somit wird der Uses - Abschnitt wieder überschaubar und du vermeidest, dass deine Komponentenunits sich irgendwann unüberschaubar gegenseitig referenzieren.

Cu, Frank

[Elvis]

Zitat von dataspider:

bei der ganzen Diskussion weise ich dennoch darauf hin, dass es keinen Sinn macht, jede Komponente in eine eigene Unit zu verfrachten. Man kann sich die Delphi VCL schon als Vorlage benutzen.
...
Somit wird der Uses - Abschnitt wieder überschaubar und du vermeidest, dass deine Komponentenunits sich irgendwann unüberschaubar gegenseitig referenzieren.

Du hast schon meinen Post gelesen, oder?
Diese übermüllten Units mit mehr als 10 oder gar 20 ( ) Typen finde absolut ekelerregend.
Sie sind immer größer als ein Monitor, das heißt man muss immer scrollen um einen Typen in seiner Gänze sehen zu können.
Wie zum Geier soll eine überschaubare uses-Clause unleserlichen Code rechtfertigen können? Vor allem wenn man (zumindest in native Delphi) das ganze mit enem ganz einfachen Trick umgehen kann?

[dataspider]

Zitat von Elvis:

Du hast schon meinen Post gelesen, oder?
Diese übermüllten Units mit mehr als 10 oder gar 20 ( ) Typen finde absolut ekelerregend.
Sie sind immer größer als ein Monitor, das heißt man muss immer scrollen um einen Typen in seiner Gänze sehen zu können.
Wie zum Geier soll eine überschaubare uses-Clause unleserlichen Code rechtfertigen können? Vor allem wenn man (zumindest in native Delphi) das ganze mit enem ganz einfachen Trick umgehen kann?

Da ich mit dem ModelMaker CodeExplorer code, kann ich das mit der Unübersichtlichkeit nicht nachvollziehen.
Und - sorry - es ist sicher Geschmacksfrage. Aber ich möchte z.B. nicht zwischen hunderten von Units in der IDE navigieren, weil ich gerade mal ein Refactoring meiner Komponenten durchführe.
Und dein Trick ist für mich ein nicht notwendiger Mehraufwand.

Cu, Frank