Vertseh das mit den Units noch nicht richtig.

[Andy Nightingale]

Hallo Leute,
Ich check das noch nicht richtig mit den Units und wie man das mit dem Vererben genau macht. Meine Idee ist praktisch das ich eine Unit machen möchte wo ich alle Suchfunktionen für Felder und deren AufrufButton reinmache. Weil dies sich in Zukunft viel wiederholen wird. Dann kann man ja anscheinend mehrere Methode von der Unit "Suchen" einfach aufrufen für seinen neuen Button und seinem Suchfeld z.B. in einem anderen Fenster. Vertehe ich das so richtig?
Wie mache ich das und gibt es dafür ein Beispiel.- also einfach. Ich hoffe das ich das richtig erklärt habe. Grüße

[TSchnuckenbock]

"Units" und "Vererben" sind zwei unterschiedliche Dinge.

"Vererben" findet in der Klassen-Architektur statt, also daß du eine Klasse hast, z.B. "TMyBaseClass" und davon dann eine oder mehrere Unterklassen ableitest, die dann natürlich andere Klassennamen haben.
Schau mal unter

https://www.delphi-treff.de/object-pascal/vererbung/

oder

https://de.wikibooks.org/wiki/Programmi ... _Vererbung

"Units" sind schlicht die Dateien, in denen du den ganzen Krams hast, also die Datenstrukturen, Klassen, Records, Funktionen und Prozeduren (Methode) usw.
Wie man dann diesen ganzen Krams auf verschiedene Units aufteilt, ist dann die Kunst.
Man kann sich z.B. eine Unit schaffen, in der alle möglichen Funktionen und Prozeduren definiert sind, die man allgemein im Programm an verschiedenen Stellen benötigt.
Jede Klasse (TBlaBlaBla = class(TObject)...) in einer Unit als grobe Richtschnur wird meist von mir bevorzugt, besonders, wenn die Klassen jeweils umfangreich sind. So behält man eine gewisse Ordnung.
Die Dateinamen der Units orientieren sich dann an der Klasse bzw. an dem Inhalt, der drin ist, so daß man anhand des Units-Namens schon ahnt, was das ist.

Damit man in einer Unit irgendeine Methode, Record, Variable oder Klasse aus einer anderen Unit (Datei) nutzen kann, muß man die zugehörige Unit in den Uses-Abschnitt packen.
Das kann manchmal zu "zirkulären Referenzen" führen, was man verhindern muß, weil der Compiler das nicht will.

[Niesi]

Units stammen aus einer Zeit, als es noch keine Objektorientierung gab - es ist eine Möglichkeit, den Quelltext in besser handhabbare Teile aufzuteilen - und auch in mehreren Programmen wieder zu verwenden.

Methoden haben die Klassen, ebenso die Eigenschaften. Units haben den Quelltext von Klassen, Funktionen, Prozeduren, Variablen, Konstanten usw., und werden dann mittels "uses" eingebunden.

Wie TSchnuckenbock schon schrieb: Es ist eine gewisse Kunst, den Quelltext sinnvoll aufzuteilen, nicht immer ganz einfach. Da hilft nur: Üben. Und den eigenen "Stil" finden, Fremdvorgaben sind meist eher nicht hilfreich, Logik hingegen schon ...

[Mathias]

Was ich meistens mache, wen man mit classen/object arbeitet.
Die Unit nenne ich als Beispiel OpenGL und die classe dann TOpenGL. Dann hat man eine gute Unterscheidung.
Oder wen ich eine Package mache, fangen alle Units mit zB. "ogl_xxx" an, dann weis man sofort, das die Units zusammen gehören.

[jammernich]

@Andy Nightingale: Also wenn ich das richtig verstehe willst du mit Lazarus loslegen und an einer GUI-Anwendung herumbasteln, dann eigenen Code bzw. Klassen in Units auslagern?

wichtig ist die Projektstruktur, siehe auch Projekt -> Projektinspektor:

projektinspektor.png (20.45 KiB) 2299 mal betrachtet

Der Inspektor zeigt alle Dateien des Projekts.
Projekt1.lpr ist quasi das "Hauptprogramm" aus dem die Anwendung compiliert wird (wird unter Windows dann z.B. zu projekt1.exe).
unit1.pas und alle anderen sind "Units".

Ich habe leider kein Beispiel für LCL-Anwendungen, aber es lohnt sich etwas einfacher anzufangen und Units, Klassen, Vererbung usw. am Beispiel zu lernen. Es ist eine systematische Einführung in "Object Pascal".
https://castle-engine.io/modern_pascal
Autor: Michalis Kamburelis

[theo]

Ein Weg zum Glück ist auch, GUI vom "Arbeitscode" zu trennen.
Irgendwann macht man das automatisch, aber am Anfang kann ich mir vorstellen, dass man das zu sehr vermischt.
Also z.B. eine Funktion, die in einer Unit irgendwas berechnet liefert ein Resultat, füllt aber selber keine GUI-Elemente (Edits, StringGrids, Memos...).
Das macht man idealerweise nur in der Hauptunit.

[af0815]

Ich bin mittlerweile ein Freund von Kapselungen.

Daher sollte die Unit, soweit wie möglich auf Querverweise verzichten, in sich gekapselt sein und vor allen auch testbar sein. Klar ist das bei reinen GUIs etwas schwerer. Deswegen verwende ich gern Frames und gestalte die, soweit wie möglich testbar aus. Damit kann ich eine Testumgebung schaffen, wo ich nur das Frame teste und später fast blind (wie eine BlackBox) in die fertige App übernehme, oder auch in andere Apps. Somit habe ich im laufe der Zeit einen echten Baukasten, den ich verwenden kann. Ohne das Rad jedesmal neu zu erfinden.

[Andy Nightingale]

Units stammen aus einer Zeit, als es noch keine Objektorientierung gab - es ist eine Möglichkeit, den Quelltext in besser handhabbare Teile aufzuteilen - und auch in mehreren Programmen wieder zu verwenden.

Methoden haben die Klassen, ebenso die Eigenschaften. Units haben den Quelltext von Klassen, Funktionen, Prozeduren, Variablen, Konstanten usw., und werden dann mittels "uses" eingebunden.

Wie TSchnuckenbock schon schrieb: Es ist eine gewisse Kunst, den Quelltext sinnvoll aufzuteilen, nicht immer ganz einfach. Da hilft nur: Üben. Und den eigenen "Stil" finden, Fremdvorgaben sind meist eher nicht hilfreich, Logik hingegen schon ...

Hallo Niesi,
danke für die Erklärung. Wie bekomme ich denn eine Unit in ein anderes Projekt?

[Andy Nightingale]

"Units" und "Vererben" sind zwei unterschiedliche Dinge.

"Vererben" findet in der Klassen-Architektur statt, also daß du eine Klasse hast, z.B. "TMyBaseClass" und davon dann eine oder mehrere Unterklassen ableitest, die dann natürlich andere Klassennamen haben.
Schau mal unter

https://www.delphi-treff.de/object-pascal/vererbung/

oder

https://de.wikibooks.org/wiki/Programmi ... _Vererbung

"Units" sind schlicht die Dateien, in denen du den ganzen Krams hast, also die Datenstrukturen, Klassen, Records, Funktionen und Prozeduren (Methode) usw.
Wie man dann diesen ganzen Krams auf verschiedene Units aufteilt, ist dann die Kunst.
Man kann sich z.B. eine Unit schaffen, in der alle möglichen Funktionen und Prozeduren definiert sind, die man allgemein im Programm an verschiedenen Stellen benötigt.
Jede Klasse (TBlaBlaBla = class(TObject)...) in einer Unit als grobe Richtschnur wird meist von mir bevorzugt, besonders, wenn die Klassen jeweils umfangreich sind. So behält man eine gewisse Ordnung.
Die Dateinamen der Units orientieren sich dann an der Klasse bzw. an dem Inhalt, der drin ist, so daß man anhand des Units-Namens schon ahnt, was das ist.

Damit man in einer Unit irgendeine Methode, Record, Variable oder Klasse aus einer anderen Unit (Datei) nutzen kann, muß man die zugehörige Unit in den Uses-Abschnitt packen.
Das kann manchmal zu "zirkulären Referenzen" führen, was man verhindern muß, weil der Compiler das nicht will.

Hallo TSchnuckenbock,
danke für die Links.- das man die Units in die Uses packen muß habe ich verstanden.....wie bekomme ich denn eine Unit von einem anderen Projekt in ein neues Projekt? Gibt es da eine elegante Weise wie ich das machen kann?

[Andy Nightingale]

@Andy Nightingale: Also wenn ich das richtig verstehe willst du mit Lazarus loslegen und an einer GUI-Anwendung herumbasteln, dann eigenen Code bzw. Klassen in Units auslagern?

wichtig ist die Projektstruktur, siehe auch Projekt -> Projektinspektor:
projektinspektor.png
Der Inspektor zeigt alle Dateien des Projekts.
Projekt1.lpr ist quasi das "Hauptprogramm" aus dem die Anwendung compiliert wird (wird unter Windows dann z.B. zu projekt1.exe).
unit1.pas und alle anderen sind "Units".

Ich habe leider kein Beispiel für LCL-Anwendungen, aber es lohnt sich etwas einfacher anzufangen und Units, Klassen, Vererbung usw. am Beispiel zu lernen. Es ist eine systematische Einführung in "Object Pascal".
https://castle-engine.io/modern_pascal
Autor: Michalis Kamburelis

Danke Jammernich,
ich werde mir das ansehen.

[Andy Nightingale]

Ein Weg zum Glück ist auch, GUI vom "Arbeitscode" zu trennen.
Irgendwann macht man das automatisch, aber am Anfang kann ich mir vorstellen, dass man das zu sehr vermischt.
Also z.B. eine Funktion, die in einer Unit irgendwas berechnet liefert ein Resultat, füllt aber selber keine GUI-Elemente (Edits, StringGrids, Memos...).
Das macht man idealerweise nur in der Hauptunit.

Hallo Theo,
ok .- wie trenne ich das denn? Grüße

[Andy Nightingale]

Ich bin mittlerweile ein Freund von Kapselungen.

Daher sollte die Unit, soweit wie möglich auf Querverweise verzichten, in sich gekapselt sein und vor allen auch testbar sein. Klar ist das bei reinen GUIs etwas schwerer. Deswegen verwende ich gern Frames und gestalte die, soweit wie möglich testbar aus. Damit kann ich eine Testumgebung schaffen, wo ich nur das Frame teste und später fast blind (wie eine BlackBox) in die fertige App übernehme, oder auch in andere Apps. Somit habe ich im laufe der Zeit einen echten Baukasten, den ich verwenden kann. Ohne das Rad jedesmal neu zu erfinden.

Hallo af0815,
das klingt ja spannend, aber nützt mir nichts wenn ich nicht weiß wie du das machst. Wahrscheinlich ist das wieder etwas für Profis und du wirst wieder sagen:....fang mit kleinen Sachen an. Danke trotzdem

[fliegermichl]

Wenn eine Unit in mehreren Projekten zur Anwendung kommen soll, dann verpackt man die am besten in ein eigenes Package, welches dann von den verschiedenen Projekten genutzt wird.

[Andy Nightingale]

Ok verstehe,- werde mal nachsehen wie das mit dem Package geht. Danke dir.

[fliegermichl]

Ok verstehe,- werde mal nachsehen wie das mit dem Package geht. Danke dir.

Das ist eigentlich fast selbsterklärend. Package -> Neues Package. Dann vergibst du einen Namen dafür.
In dem Package Fenster klickst du auf hinzufügen. Dort wählst du die Unit aus und klickst dann auf kompilieren.

In deinem Projekte gehst du auf Projekt -> Projekt Inspektor und klickst auf "neue Anforderung hinzufügen". Da gibst du den Namen deines Packages an.
Das war's dann auch schon.