function mit pointer als Rückgabewert - Teil 2

[Mr. No]

Habe leider immer noch ein Problem mit der Deklaration

Zitat:

Delphi-Quellcode:

uses meinObjekt, ...
type
  TMainForm = class(TForm)
  ...
private
  ...
public
  function GetMeinObjekt: TmeinObjekt;
  ...
end;



var
  MyObject: TmeinObjekt;

  function TMainForm.GetMeinObjekt: TmeinObjekt;
begin
  Result := MyObject;
end;

funktioniert nicht, da ich in der ersten Zeile einen "überkreuzenden Bezug zweier Units habe"

wenn ich stattdessen schreibe

Delphi-Quellcode:

type
  TMainForm = class(TForm)
  ...
private
  ...
public
  function GetMeinObjekt: TmeinObjekt;
  ...
end;

uses meinObjekt, ...

var
  MyObject: TmeinObjekt;

  function TMainForm.GetMeinObjekt: TmeinObjekt;
begin
  Result := MyObject;
end;

bekomme ich die Fehlermeldung:
"Deklaration von GetMeinObjekt unterscheidet sich von vorheriger Deklaration"

es scheint, als müsste ich uses meinObjekt, ... vor der Funktionsdeklaration von "GetMeinObjekt" deklarieren. - Aber das funktioniert ja nicht.

?? - Totale Verwirrung - ??

Was kann man da machen?

[sniper_w]

Die Frage ist nicht kompllet, was willst du eigentlich ?

[Mr. No]

also in erster Linie keine Fehlermeldung mehr.

ich möchte eigentlich nur meine GetMeinObjekt-Funktion implementieren

[Pseudemys Nelsoni]

hi

@Mr.No

da du einen typ aus deiner unit bereits innerhalb des interfaces brauchst, musste die unit natürlich auch da haben und nicht im implementationsteil.

n tip: mach am besten alles in eine unit, dann gibts keine probleme... du kannst es auch über 3 units machen, da steht hier aber auch schon oft im forum.

[tommie-lie]

Zitat:

Zitat von Pseudemys Nelsoni

da du einen typ aus deiner unit bereits innerhalb des interfaces brauchst, musste die unit natürlich auch da haben und nicht im implementationsteil.

Wie du siehst, hat er das schon versucht, und bekam dann 'ne Fehlermeldung ;-)

Zitat:

Zitat von Mr. No

funktioniert nicht, da ich in der ersten Zeile einen "überkreuzenden Bezug zweier Units habe"

Wahrscheinlich steht deine Unit auch in meinObjekt.pas wieder im interface in der uses-Anweisung. Du verweist also auf meinObjekt, das wieder auf deine Unit verweist, das wieder auf meinObjekt verweist und so weiter. Du solltest versuchen, solche Überkreuzungen rauszubekommen. Das ganze betrifft nur Units, die im interface-Teil stehen, in implementation kannst du Units benutzen, die selbst deine Unit weider benutzen, da gibt es keine Probleme. Eine Möglichkeit wäre wie von Mario angesprochen, daß du die Klassen in nur einer Unit deklarierst.

[Pseudemys Nelsoni]

Marco? :gruebel: :cry:

Zitat:

Wie du siehst, hat er das schon versucht, und bekam dann 'ne Fehlermeldung

jo, ich meine auch eher allgemein ;)

[tommie-lie]

Zitat:

Zitat von Pseudemys Nelsoni

Marco? :gruebel: :cry:

Hab' ich nie geschrieben! :angel2: :mrgreen:

[Mr. No]

hm - gibt's da keine Möglichkeit, in beiden Units aufeinander zu verweisen? In C++ ist's doch auch möglich, dass in den Headerdateien solche Bezüge hergestellt werden

[Phoenix]

Nein, und das ist auch gut so :)

Die Form braucht Dein Objekt, aber Dein Objekt darf die Form nicht verwenden.
Oder Andersrum: Dein Objekt verwendet die Form, dann darf die Form aber Dein Objekt nicht verwenden.

Ich verwende einen Hammer, aber der Hammer darf nie und nimmer mich verwenden.
Mein Haus braucht Nägel, aber ein Nagel braucht kein Haus.
Mein Computer braucht Strom, aber Strom braucht meinen Computer nicht.

Also wie gesagt: Entwder Du bindest eine dritte Unit ein, packst alles in die gleiche oder aber Du räumst so auf, das wirklich ein logischer Bezug entsteht und keine Henne-Ei-Problematik.

[Mr. No]

außerdem ist mir gerade aufgefallen - in der Main-Unit verweise ich im uses-Teil des interfaces auf meine Objekt-Unit - hier tritt der Fehler auf - aber in der Objekt-Unit, steht unter uses lediglich Forms, aber sonst kein Verweis auf die Main-Unit.
Woher kann dann überhaupt der Fehler "Überkreuzender Bezug zweier Units auf 'Main'" kommen?

[EDIT]
stimmt leider doch nicht so ganz - es gibt einen überkreuzenden Bezug

[Phoenix]

Poste doch bitte mal die die kompletten interface-Teile beider Units mit den entsprechenden Uses-Klauseln.

[Mr. No]

Mein Problem wäre gelöst, wenn man einen Pointer auf ein Memo-Feld setzen könnte. Ist so etwas möglich?

Ich müsste dann im Konstruktor meines Objektes einen Pointer mitgeben

Delphi-Quellcode:

constructor Create(Feld: TMemo);

geht schon mal nicht :roll:

[Pseudemys Nelsoni]

Zitat:

Hab' ich nie geschrieben!

:mrgreen:

Zitat:

Ich verwende einen Hammer, aber der Hammer darf nie und nimmer mich verwenden.
Mein Haus braucht Nägel, aber ein Nagel braucht kein Haus.
Mein Computer braucht Strom, aber Strom braucht meinen Computer nicht.

das sind aber üble beispiele <g>

Mein Kakao brauch nämlich Kakaopulver und Milch =)

[Phoenix]

Zitat:

Zitat von Pseudemys Nelsoni

Mein Kakao brauch nämlich Kakaopulver und Milch =)

Aber die Milch braucht Deine Trinkschokolade nicht und das Kakaopulver erst recht nicht :-p

[Mr. No]

aber ich brauche eine Lösung :(

[Pseudemys Nelsoni]

wurden dir doch oben genannt...

[Phoenix]

Zitat:

Zitat von Mr. No

aber ich brauche eine Lösung :(

Dann Poste bitte mal Deine beiden Units bis zum Anfang vom Implementation-Teil.

[Robert_G]

Zitat:

Zitat von Mr. No

aber ich brauche eine Lösung :(

Wurde schon mehrfach genannt. ;)

btw: Warum sich der Delphi Compiler die Units nicht merken kann, die er schon durchlaufen ist, frage ich allerdings auch ständig. :roll: (Naja seid ein paar Monaten frage ich mich das eigentlich nicht mehr ganz so oft :mrgreen: )
Eigentlich wäre dadurch eine Endlosschleife aus Querverweisen gar nicht möglich.

[tommie-lie]

Zitat:

Zitat von Mr. No

Ich müsste dann im Konstruktor meines Objektes einen Pointer mitgeben

Delphi-Quellcode:

constructor Create(Feld: TMemo);

geht schon mal nicht :roll:

Warum nicht? Sieht doch gut aus. Oder hast du vergessen die StdCtrls einzubinden?


@Phoenix: Gerade bei Klassen haben solche Dinge durchaus ihre Existenzberechtigung, wenn man Klassen nicht in noch eine weitere Unit auslagern will, weil sie eigentlich logisch in einer anderen Unit besser aufgehoben wären.

Zitat:

Zitat von Robert_G

Warum sich der Delphi Compiler die Units nicht merken kann, die er schon durchlaufen ist, frage ich allerdings auch ständig. :roll:
Eigentlich wäre dadurch eine Endlosschleife aus Querverweisen gar nicht möglich.

Er merkt sie sich wohl nicht, weil eine solche Information eigentlich uninteressant ist und eh nur für den Parser benötigt wird, die DCUs werden eh später vom Linker zusammengepfriemelt.

[Robert_G]

Ich meinte das:

Delphi-Quellcode:

unit a
uses b

Delphi-Quellcode:

unit b
uses a

Ich sehe da keinen triftigen Grund für eine Zirkulärreferenz.
Er muss sich doch nur a UND b angucken!
In .Net geht es sogar soweit, dass ich nur noch sage: Hier ist ein Namespace -> suche dir gefälligst die passenden Dateien und nerve mich bloss nicht damit. ;)

[Mr. No]

mit

Delphi-Quellcode:

      constructor  Create(myEditor: TCustomMemo);

klappt alles blendend.

Danke für Eure Hilfe!!

[tommie-lie]

Zitat:

Zitat von Robert_G

In .Net geht es sogar soweit, dass ich nur noch sage: Hier ist ein Namespace -> suche dir gefälligst die passenden Dateien und nerve mich bloss nicht damit. ;)

Wir sind uns doch beide einig, daß in .NET alles ein wenig schöner ist, als in Delphi, insbesondere alles, was mit Klassen und Hierachie zu tun hat ;-)