Zugriff auf Label aus "externer" Unit

[Zero8fifteen]

Hallo,

hab ein Problem, trotz langer Suche nix gefunden.

Auf das Wesentliche reduziert hab ich ein kleines Programm (unit1 und Form1), und zusätzlich noch eine "externe" Unit2, in der ich ein paar Prozeduren deklariert habe, die ich im Programm benütze.

Das funktioniert soweit einwandfrei, nur wenn ich aus einer Prozedur der Unit2 auf Objekte (einfach ein Label) der Form1 zugreifen will, kommt beim compilen der Fehler <Undeclared identifier: 'label1'>

Irgendwie muss da noch rein, dass ich auf das "label1" der FORM1 zugreifen will, ich brings einfach nicht raus WIE!

Wie gesagt, sonst funktionieren die Prozeduren, lediglich der Zugriff auf das Label ist das Problem.

Danke schonmal ...

Markus

(Delphi6)

[mkinzler]

Ubergebe das Label besser als Parameter

[messie]

Eine etwas weniger sparsame Antwort:

Wenn Du vorher die Funktion hattest

Delphi-Quellcode:

procedure BerechneIrgendwas;
begin
  //machwas
  Ergebnis := FloatToStr(machwas);
  Form1.Label1.Caption := Ergebnis;
end;

dann muss die Unit1, zu der Form1 gehört in der uses-Zeile von Unit2 erscheinen.

mkinzler schlägt vor:

Delphi-Quellcode:

procedure BerechneIrgendwas(OutLabel : TLabel);
begin
  //machwas
  Ergebnis := FloatToStr(machwas);
  OutLabel.Caption := Ergebnis;
end;

Der Aufruf aus Form1 würde lauten

Delphi-Quellcode:

Unit2.Berechneirgendwas(Label1);

Das ist dann gut, wenn Du die Routine direkt aus Form1 und nur einmal aufrufst. Wird sie von anderen Routinen von Unit2 oder rekursiv aufgerufen, ist die erste Variante besser.

Grüße, Messie

[mkinzler]

Zitat:

Das ist dann gut, wenn Du die Routine direkt aus Form1 und nur einmal aufrufst. Wird sie von anderen Routinen von Unit2 oder rekursiv aufgerufen, ist die erste Variante besser.

Warum bitte das? Wenn du das Ausgabelabel mitgibst kannst du es von überall aufrufen.

[messie]

Zitat:

Zitat von mkinzler

Warum bitte das? Wenn du das Ausgabelabel mitgibst kannst du es von überall aufrufen.

Ich meinte, falls die Routine nicht direkt aus Form1 aufgerufen wird, sondern z.B. proc1 ruft proc2 auf, proc2 ruft Ergebnisprozedur proc3 auf etc. Dann müsste das Label bis proc3 durchgereicht werden. Und da ist ein anderer Aufbau - welcher Form auch immer - sinnvoller.

Grüße, Messie

[SirThornberry]

nein, auch dann ist es nicht sinnvoller. Denn wenn Irgendwann Form1 in Formx umbenannt wird muss man es an zig stellen ändern. Oder wenn irgendwann Form1 gar nicht instanziert wird sondern dynamisch das Form auf eine andere Variable angelegt wird dann kracht es weil Form1 nicht instanziert ist.
Delphi steht für Objectpascal und wenn man mit TForm arbeitet verwendet man bereits Klassen und es macht keinen Sinn das dann mit globaler Programmierung zu vermixen wenn es auch anders geht.

[Zero8fifteen]

Danke erstmal,

ich hab an die erste (einfachere) Möglichkeit gedacht, die funktioniert aber immer noch nicht.

Die Zeilen

Delphi-Quellcode:

 label1.caption := inttostr(ergebnis);       // geht nicht: <Undeclared identifier: 'label1'>
 
 form1.label1.caption := inttostr(ergebnis); // geht auch nicht: <Undeclared identifier: 'form1'>

liefern die entsprechenden Fehler.


Wenn ich nun in die uses-Zeile der Unit2 die Unit1 reinschreibe, kommt beim compilen der Fehler <Circular unit reference>, man darf da also offensichtlich nicht gleichzeitig in Unit1 auf Unit2 und umgekehrt verweisen.


Nun ja, die andere Variante mit dem Ausgabelabel funktioniert jedenfalls tadellos, das Programm läuft!

Vielen Dank also!

[DeddyH]

Wenn Du 2 Units hast, die sich gegenseitig referenzieren, musst Du in der einen die uses-Klausel im interface-Abschnitt erweitern und in der anderen die im implementation-Abschnitt.

[mkinzler]

Zitat:

Wenn ich nun in die uses-Zeile der Unit2 die Unit1 reinschreibe, kommt beim compilen der Fehler <Circular unit reference>, man darf da also offensichtlich nicht gleichzeitig in Unit1 auf Unit2 und umgekehrt verweisen.

Das würde gehen, wenn du Unit1 in Unit2 unter implementation einbindest. Die Lösung mit dem Parameter ist aber die sauberere und bessere Lösung.

[messie]

Zitat:

Zitat von SirThornberry

nein, auch dann ist es nicht sinnvoller. Denn wenn Irgendwann Form1 in Formx umbenannt wird muss man es an zig stellen ändern. Oder wenn irgendwann Form1 gar nicht instanziert wird sondern dynamisch das Form auf eine andere Variable angelegt wird dann kracht es weil Form1 nicht instanziert ist.
Delphi steht für Objectpascal und wenn man mit TForm arbeitet verwendet man bereits Klassen und es macht keinen Sinn das dann mit globaler Programmierung zu vermixen wenn es auch anders geht.

Keiner versteht mich... :cry:
Angesichts der posts glaube ich aber auch, dass Zero8fifteen Deine Erläuterung nicht gleich verstehen wird. Ich wollte es so einfach wie möglich aufgabenbezogen darstellen. Und Vereinfachungen enthalten nun mal nicht alle Informationen und sind auch nicht immer vollständig richtig, ja nach Grad der Vereinfachung.

Grüße, Messie