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

[mkinzler]

Bei einem obejektorientierten Design sollte man so wenig wie möglich feste Instanzen adressieren.

[Hansa]

Man sollte tunlichst vermeiden, eine Form aus einer anderen aufzurufen. Das ist schlechter Stil und zwar zurecht. Wenn ich schon Form1 sehe (Betonung liegt auf 1!), :twisted: dann sieht es nach sehr schlecht überlegtem Form-Design aus. Die Prozedur hat anscheinend auch nur zufällig was mit einem Form zu tun. Insofern liegt nahe, solche Sachen in eine allgemeine Unit auszulagern.

[messie]

Zitat:

Zitat von mkinzler

Bei einem objektorientierten Design sollte man so wenig wie möglich feste Instanzen adressieren.

Keiner versteht mich und keiner hört mir zu (bzw. keiner liest mich)! Mit Deiner Aussage kann der ThreaderstellerIn mit einiger Sicherheit nix anfangen.

Braucht die DP vielleicht ein Anfängerforum?

Grüße, Messie

[SirThornberry]

Zitat:

Zitat von messie

Zitat:

Zitat von mkinzler

Bei einem objektorientierten Design sollte man so wenig wie möglich feste Instanzen adressieren.

Keiner versteht mich und keiner hört mir zu (bzw. keiner liest mich)! Mit Deiner Aussage kann der ThreaderstellerIn mit einiger Sicherheit nix anfangen.

Braucht die DP vielleicht ein Anfängerforum?

Grüße, Messie

Das stimmt so nicht ganz. Ich verstehe was du meinst aber ich finde es falsch Anfängern falsch bei zu bringen. Die Umstellung fällt später nicht gerade leicht. Ich hatte bereits mehrfach leute im Team welche so programmiert haben und es hat immer Probleme gemacht sobald man etwas (hauptsächlich komponenten oder Fenster) im Nachhinein mehrfach brauchte.

[Hansa]

Zitat:

Zitat von SirThornberry

...und es hat immer Probleme gemacht sobald man etwas (hauptsächlich komponenten oder Fenster) im Nachhinein mehrfach brauchte.

Das will er wohl kaum wissen. Warum soll eine "freischwebende" Prozedur in eine Form gezwängt werden ? Da hakts in der Logik. Um etwas wieder-/mehrfach zu verwenden hat man Units (Ausnahme : Forms). Sofern es sich um Formular-Eigenschaften handelt, dann ist dafür die Objektablage zuständig. Siehe auch "Entwickler" von letzter Woche (02/08 ).

Edit : Für Forum-Bastler : 8) <= in Worten "Acht als Zahl "+) ergibt -> 8) :mrgreen:

[messie]

Zitat:

Zitat von SirThornberry

Das stimmt so nicht ganz. Ich verstehe was du meinst aber ich finde es falsch Anfängern falsch bei zu bringen.

Ich versuche ja nur, zu vereinfachen. Vereinfachen sollte auch nicht falsch sein, aber ich hab' vom Programmieren nun mal kaum Ahnung. Aber versucht, eine Lösung einfach und verständlich darzustellen für jemanden der nicht mindestens vier Semester Informatik hinter sich hat.

Übrigens passt Deine Signatur nicht so recht zu Deinen Aussagen...

Grüße, Messie