Verfügbarkeit öffendlicher Units

[LarsSchwencke]

Hallo,

mit der verfügbarkeit öffendlich deklarierter Units stehe ich
offensichtlich auf Kriegsfuß.
Auch scheint das Kapittel 6.1.2 im Borland Delphi 7 Grundlagen und Profiwissen
bei Delphi XE4 nicht zu funktionieren.

Mein Problem, 3 Units.
Die Unit 2 verwendet die Unit 3.
Die Unit 1 die Unit 2 und sollte aber auch die Funktionen der Unit 3 nutzen können.

Sollte es nicht so funktionieren?

Unit3:

Delphi-Quellcode:

unit Unit3;

interface

function Test3(): integer;

implementation

function Test3(): integer;
begin
...
end;

end.

Unit2

Delphi-Quellcode:

unit Unit2;

interface

uses Unit3;

function Test2(): integer;

implementation

function Test2(): integer;
var
  iCounter2: integer

begin
 iCounter2 := Test3();
end;
end.

Unit1

Delphi-Quellcode:

unit Unit1;

interface


function Test1(): integer;

implementation

uses Unit2;

function Test1(): integer;
var
  iCounter1: integer

begin
 iCounter1 := Test3();     // E2003 Undeklarierter Bezeichner: 'Test3' 
end;
end.

Kann mir jemand mitteilen, wie sich dies realisieren läßt?

Vielen Dank für alle Infos.

MfG
Lars

[DeddyH]

Wenn Unit1 Funktionen aus Unit3 benutzen soll, muss sie auch Unit3 kennen.

[baumina]

Alle die Units, die du nicht innerhalb des interfaces brauchst in der uses-Liste unterhalb der implementation angeben.

Delphi-Quellcode:

unit xxx;

Interface

uses ..., ...; // hier wenn es im Interface gebraucht wird

implementation

uses ..., ...; // hier wenn es Nicht im Interface gebraucht wird

[EWeiss]

Zitat:

Zitat von DeddyH (Beitrag 1244067)

Wenn Unit1 Funktionen aus Unit3 benutzen soll, muss sie auch Unit3 kennen.

Sag ihm doch das er sie unter Uses in der unit 1 noch mit einbinden muss. ;)

gruss

[DeddyH]

Das ist ja die logische Konsequenz des Gesagten.

[LarsSchwencke]

Ja sicher,

das kann ich machen, war nur nicht meine Idee,
und in dem Buch steht:

Ich zietiere aus dem Buch Borland 7 Grundlagen und Profiwissen:

"Öffendlich (public) Deklaparion
In diesem Fall erscheint die uses-Klausel unmittelbar nach dem Wort interface.
Programme bzw. andere Units, die die Aktuelle Unit benutzen, können also auch zusätzlich
auf die hier angeführten Units zugreifen."

Dann sollte es ja auch funtionieren, die Frage, ist es bei Delphi XE4 anders?

MfG
Lars

[DeddyH]

Das wäre mir jetzt neu, in dem Punkt scheint im Buch einfach etwas Falsches zu stehen.

[jaenicke]

In den Büchern waren mir auch noch ein paar andere Punkte aufgefallen. Die hatte ich damals auch an die Autoren geschickt, habe aber keinerlei Antwort bekommen.

Das war eines der wenigen Bücher, die ich beim Lernen von Delphi in die Hand genommen hatte. Geholfen haben sie mir nicht wirklich. Ausprobieren, die mitgelieferten Beispiele und Quelltexte und die Hilfe haben mir viel mehr geholfen.

[himitsu]

Du kannst dir einfach merken, daß man nur das sieht, was "direkt" in den in Uses angegebenen Units enthalten ist
und zwar in der Reihenfolge von der letzten zur ersten Unit.


Das ist also ganz einfach komplett falsch, was da steht.

Von dem, was im Interface ist, wird alles, was nicht private (in Klassen), grundsätzlich auch erstmal nicht protected und was auch keine Unit ist, in der aufrufenden Unit verfügbar sein,
also nur das, was auch "wirklich" da drin "sichtbar" ist.

Was man machen kann, ist z.B. einen Alias von einem Typ oder die Kopie einer Konstante, bzw. die Umleitung einer Funktion aus der Unit3 in Unit2 anzulegen und diese dann in Unit1 zu nutzen.

Bei einem gleichnamigen "Alias" ist es dann egal, ob das Original aus Unit3 oder der Alias aus Unit2 in Unit1 verwendet wird, da es intern der selbe Typ ist.

[p80286]

Das angesprochene Verhalten war unter TP noch vorhanden.

ERin Blick in die D7 OH hilft hier weiter:

Zitat:

Die Reihenfolge der Units in der uses-Klausel bestimmt die Reihenfolge der Initialisierung dieser Units (siehe Der initialization-Abschnitt) und wirkt sich auf die Suche des Compilers nach den Bezeichnern aus. Wenn zwei Units eine Variable, eine Konstante, einen Typ, eine Prozedur oder eine Funktion mit identischem Namen deklarieren, verwendet der Compiler die Deklaration der in der uses-Klausel zuletzt angegeben Unit. Wollen Sie auf den Bezeichner in einer anderen Unit zugreifen, müssen Sie den vollständigen Bezeichnernamen angeben: Unitname.Bezeichner.

Eine uses-Klausel muss nur die Units enthalten, die direkt vom Programm bzw. von der Unit verwendet werden, in dem bzw. der die uses-Klausel steht. Referenziert beispielsweise Unit A Konstanten, Typen, Variablen, Prozeduren oder Funktionen, die in Unit B deklariert sind, muss die Unit B explizit in der uses-Klausel von Unit A angegeben werden. Referenziert B wiederum Bezeichner aus Unit C, ist Unit A indirekt von Unit C abhängig. In diesem Fall muss Unit C nicht in einer uses-Klausel in Unit A angegeben werden. Der Compiler benötigt jedoch Zugriff auf die Units B und C, während Unit A verarbeitet wird.

Das folgende Beispiel illustriert diese indirekte Abhängigkeit:

program Prog;
uses Unit2;
const a = b;
...
unit Unit2;
interface
uses Unit1;
const b = c;
...
unit Unit1;
interface
const c = 1;
...

Hier hängt das Programm Prog direkt von Unit2 ab, die wiederum direkt von Unit1 abhängig ist. Prog ist also indirekt von Unit1 abhängig. Da Unit1 nicht in der uses
-Klausel von Prog angeben ist, sind die in Unit1 deklarierten Bezeichner für Prog nicht verfügbar.

Damit ein Client-Modul compiliert werden kann, muss der Compiler Zugriff auf alle Units haben, von denen der Client direkt oder indirekt abhängt. Sofern der Quelltext dieser Units nicht geändert wurde, benötigt der Compiler nur die .DCU-Dateien (Windows) bzw. die .DCU/.DPU-Dateien (Linux), nicht jedoch die Quelltextdateien (.PAS). Wenn es sich bei dem Linkpartner um ein Package handelt.

Werden im interface-Abschnitt einer Unit Änderungen vorgenommen, müssen die von dieser Unit abhängigen Units neu compiliert werden. Werden die Änderungen dagegen nur im implementation- oder einem anderen Abschnitt einer Unit vorgenommen, müssen die abhängigen Units nicht neu compiliert werden. Der Compiler überwacht diese Abhängigkeiten und nimmt Neucompilierungen nur vor, wenn dies erforderlich ist.

Gruß
K-H