Unit Aufbau

[Ruffy87]

Hallo,

zuerst mal ein kleiner Screenshot vom CodeExplorer:

http://people.freenet.de/www.ruffy.de/DelphiUnit.jpg

Jetzt meine Frage dazu:
Was ist der Unterschied wenn ich eine procedure in den Teil von "TFormHaupt->Public/Private"
oder direkt in den "Ordner Proceduren" schreibe?

So wie ich das in der Schule verstanden habe:
Der Public Teil ist dafür da, damit man von anderen Units auf die Methoden
im Public Teil drauf zugreifen kann. Dann gibt es noch einen Private Teil
der nur für die Methoden intern in der Unit ist.

Wofür ist dann der Eintrag "Prozeduren" auf der Ebene von "TFormHaupt" da?

Mit freundlichen Grüßen

Stefan

[ichbins]

wenn du sie in den private-Bereich des Forms schreibst, dann gehört die Prozedur/Funktion der Form, also der Klasse. Diese nennt sich dann METHODE. Um sie aufzurufen, brauchst du eine Variable vom Typ der Klasse (also TFormhaupt), deren Funktion du dann aufrufst, also so:
unit1.formhaupt1.methode; Von dieser Methode aus kannst du dierekt Untereigenschaften oder andere Methoden der Form zugreifen, also einfach so:

Delphi-Quellcode:

methode2;
//oder
button1.caption:='';

Wenn du die Prozedur in die Unit schreibst, ist sie dierekt von der Unit abhängig und nicht von einer Klasse:
unit1.prozedur; alle Prozeduren wie buttonclick oder so sind Methoden der Form.


Wenn du auf Komponenten oder Eigenschaften der Form zugreifen willst, dann verwende Methoden, wenn du unabhängige Funktionen schreiben willst, Funktionen und Prozeduren dierekt in der Unit.



Die Unterbereiche Public und Private beschreiben, wie du schon gesagt hast, die Zugriffsrechte auf die Methoden und Eigenschaften der Klasse. Wenn du sie in private schreibst, kann man nur von anderen Methoden der Klasse aus darauf zugreifen, wenn du sie in public schreibst, kann man auch von Methoden anderer Klassen oder Prozeduren/Funktionen die dierekt zur Unit gehören zugreifen.

[Ruffy87]

Also zuerst mal danke für deine Antwort.

Hab die Sachen selbst noch mal testet.

1. Erkenntnis

Für den Aufruf muss man nicht noch den Unit Namen vorranstellen, sondern kann
einfach so schreiben(z.B. in einem OnClick-Ereignis der Form ist):

Code:

methode

2. Erkenntnis

Wenn ich eine Prozedur in eine Unit1 schreibe und diese von einer Unit2 aufrufen möchten
dann klappt dein angegebener Code "Unit1.prozedur" nicht.(natürlich hab ich die Unit1 in
uses von Unit2 eingebunden)
Ich glaube, das wenn ich eine Prozedur direkt in die Unit schreibe diese auch nur
in der jeweiligen Unit verwenden werden kann.

[Grishnak]

Zitat von Ruffy87:

2. Erkenntnis

Wenn ich eine Prozedur in eine Unit1 schreibe und diese von einer Unit2 aufrufen möchten
dann klappt dein angegebener Code "Unit1.prozedur" nicht.(natürlich hab ich die Unit1 in
uses von Unit2 eingebunden)
Ich glaube, das wenn ich eine Prozedur direkt in die Unit schreibe diese auch nur
in der jeweiligen Unit verwenden werden kann.

Damit du von außerhalb der Unit auf Funktionen/Prozeduren zugreifen kannst, musst du diese im "Interface"-Teil der Unit bekannt machen:

Delphi-Quellcode:

unit Test;

interface

procedure Sichtbar(a: string);

implementation

procedure Sichtbar(a: string); // kann von jeder Unit, die diese Unit per Uses einbindet aufgerufen werden
begin
  [...]
end;

procedure Unsichtbar(x: single); // kann nur innerhalb dieser Unit aufgerufen werden
begin
  [...]
end;

end.

[Der_Unwissende]

Hi,
gute Erkenntnis! Aber da gibt es noch ein wenig zu ergänzen.

Das man die Unit-namen nicht voran stellen muss, ist zwar soweit richtig. Trotzdem gibt es auch die Möglichkeit dies zu tun, bleibt die Frage warum?! Zu der Erkenntnis kommst du ganz leicht, wenn du mal zwei gleich benannte Funktionen/Prozeduren/Klassen/Konstanten/.... hast. Sagen wir der Einfachheit halber, du hast 2 Units, die eine Konstante CFILE_NAME besitzen. Seien nun beide Units in der Unit Unit3 eingebunden. Jetzt möchtest du gucken ob die beiden CFILE_NAME Werte gleich sind. Problem gibst du CFILE_NAME ein, hast du einen Wert, doch welchen? In Delphi wird das durch die Reihenfolge in der uses bestimmt (letztere sind immer "wichtiger"). Also ist es einfach sauberer / sicherer den Unitnamen voran zu stellen.

Eine andere Sache ist dass man Methoden nur in der gleichen Unit benutzen darf. Es würde natürlich wenig Sinn machen, zumal du schon einen Haufen Units in deinem Form automatisch eingebunden hast. Könntest du hiervon keine Methode benutzen, nun ja...
Es gibt einen Mechanismus, der ein wenig den Sichtbarkeiten von Klassen entspricht. Wie du in deinen Formularen siehst, gibt es zwei Abschnitte in einer Unit, Interface und Implementation.
Der Interface Teil dient der veröffentlichung von Schnittstellen (Interface). Hier wird alles das eingetragen, was nach aussen (ausserhalb der Unit) auch sichtbar ist. Natürlich sind Typdeklarationen und Konstanten auch in der gesamten Unit sichtbar.
Der Implementation Teil dient der Implementierung. Hier kommt also der Code rein. Jede nicht abstrakte, nicht geforwardete und nicht externe Prozedur/Funktion muss im Implementationteil implementiert werden.
Diese Methoden müssen implementiert werden, aber du kannst auch weitere anlegen. Diese sind dann nicht von aussen zugänglich (das Phänomen, auf dass du gestossen bist). Sie werden einfach als Hilfsmethoden für die anderen benutzt.

Gruß Der Unwissende

[Ruffy87]

Danke an alle

[Ruffy87]

Hab noch eine letzte Frage(das ist eigentlich meine Hauptfrage bei dem Thema):

Eine Methode im Public Teil muss man schreiben, wenn man diese von anderen Units aufrufen will,
das ist jetzt klar.

Wenn ich aber jetzt eine Prozedur schreiben will, die nur in der einen Unit/Form verwendet werden soll,
könnte ich die Prozedur ja entweder in den Private Teil schreiben oder direkt in die Unit.
Wann mache ich den was?

Ein Bsp. von meinem Programmcode:
1. Möglichkeit

Delphi-Quellcode:

procedure BK_Suchen(BK_Name:String; var BK: TTreeNode);
var TV_Count, BK_Index:integer;
    BK_Gefunden: Boolean;
begin
  with FormHaupt do
  begin
//Variablen initialisieren
    BK_Gefunden := false;
    TV_Count := TreeViewHaupt.Items.Count - 1;
    BK_Index := -1;

//Eintrag suchen
    repeat
      inc(BK_Index);
      BK := TreeViewHaupt.Items[BK_Index];
      if BK.Text = BK_Name then
        BK_Gefunden := true;
    until(BK_Gefunden) or (BK_Index = TV_Count);
  end;
end;

2. Möglichkeit

Delphi-Quellcode:

interface
...
  private
    procedure BK_Suchen(BK_Name:String; var BK: TTreeNode);
...
implementation
...
procedure TFormHaupt.BK_Suchen(BK_Name:String; var BK: TTreeNode);
var TV_Count, BK_Index:integer;
    BK_Gefunden: Boolean;
begin
//Variablen initialisieren
  BK_Gefunden := false;
  TV_Count := TreeViewHaupt.Items.Count - 1;
  BK_Index := -1;

//Eintrag suchen
  repeat
    inc(BK_Index);
    BK := TreeViewHaupt.Items[BK_Index];
    if BK.Text = BK_Name then
      BK_Gefunden := true;
  until(BK_Gefunden) or (BK_Index = TV_Count);
end;
...

Beides funktioniert, aber wann wende ich was an?

[xaromz]

Hallo,

Deine erste Lösung funktioniert nicht, da Du auf Eigenschaften/Objekte Deines Forms zugreifst (TreeViewHaupt). Du musst also immer
FormHaupt.TreeViewHaupt schreiben.
Was machst Du aber, wenn Du Dein Form mehrfach verwendest und das Objekt dann nicht FormHaupt heisst?

Wenn Du also auf Eigenschaften einer Klasse zugreifst (ein Formular ist ja auch eine Klasse), benutze immer die untere Lösung.

Gruß
xaromz

[Ruffy87]

Beide Lösungen funktionieren bei mir zu 100%.

Und es ist doch egal ob man schreibt:

Delphi-Quellcode:

with FormHaupt do
begin
  TreeViewHaupt.Eigenschaft;
end;

oder

FormHaupt.TreeViewHaupt.Eigenschaft;

[xaromz]

Hallo,

da hatte ich das
with FormHaupt do übersehen.

Der Rest meines Postings ist trotzdem gültig.

Gruß
xaromz