Hi,
angenommen es gibt ein komplexes Datenmodul (samt lfm-file) und ich möchte dieses in einer eigenen Unit so umschreiben dass kein LFM File mehr nötig ist, so kann ich das indem ich eine Klasse erstelle und in dieser die Creates und Destroys samt Einstellungen mache. Soweit so gut.
Weitgehend existiert dann also gleicher Code doppelt, was ich nicht so mag und fehleranfällig ist.
Gibt es irgend eine Schreib-Technik die es mir erlaubt den Code für beide Fälle, also das Datenmodul und die Unit anzubieten und den Code nur einmal zu haben?
Ich habe bisher als Lösung nur include Dateien gefunden die jeweils mit je einem File den Deklarationsbereich public und private und den Implementationsbereich abdecken unter der Voraussetzung dass dass die Klasse vom gleichen Typ ist.
Habe ich da syntaktisch etwas übersehen und es gibt andere Varianten?
THX
[Erledigt] Wiederverwendbarkeit von Code
-
- Beiträge: 843
- Registriert: Sa 12. Sep 2015, 12:10
- OS, Lazarus, FPC: Laz stable (2.2.6, 3.x)
- CPU-Target: Win 32/64, Linux64
- Wohnort: Wien
[Erledigt] Wiederverwendbarkeit von Code
Zuletzt geändert von charlytango am Di 20. Dez 2022, 21:30, insgesamt 1-mal geändert.
-
- Beiträge: 843
- Registriert: Sa 12. Sep 2015, 12:10
- OS, Lazarus, FPC: Laz stable (2.2.6, 3.x)
- CPU-Target: Win 32/64, Linux64
- Wohnort: Wien
Re: Wiederverwendbarkeit von Code
mittlerweile bin ich mit der Recherche etwas weiter.
Bei FPC werden ausgiebig Include Files verwendet.
So ein File sieht zB so aus:
Es scheint also mit read_interface und read_implementation eine Funktionalität zugeben um aus einem einzigen Includefile Interfaceteil und Implementation zusammen zu setzen. Vermutlich auch noch irgendwie intelligent eingefügt.
Kennt jemand dazu irgendwo eine Doku?
Bei FPC werden ausgiebig Include Files verwendet.
So ein File sieht zB so aus:
Code: Alles auswählen
{$IfDef read_interface}
type
TGConfError = (GCONF_ERROR_SUCCESS := 0,GCONF_ERROR_FAILED := 1,
GCONF_ERROR_NO_SERVER := 2,GCONF_ERROR_NO_PERMISSION := 3,
GCONF_ERROR_BAD_ADDRESS := 4,GCONF_ERROR_BAD_KEY := 5,
function gconf_error_quark:TGQuark;cdecl;external gconfdll name 'gconf_error_quark';
function GCONF_ERROR : TGConfError;
{$EndIf read_interface}
{$Ifdef read_implementation}
function GCONF_ERROR : TGConfError;
begin
GCONF_ERROR := TGConfError(gconf_error_quark);
end;
{$Endif read_implementation}
Kennt jemand dazu irgendwo eine Doku?
-
- Beiträge: 825
- Registriert: Mi 3. Jun 2020, 07:18
- OS, Lazarus, FPC: L 2.0.8, FPC Trunk, OS Win/Linux
- CPU-Target: Aarch64 bis Z80 ;)
- Wohnort: München
Re: Wiederverwendbarkeit von Code
Ja, mach einfac die Erstellung der einzelnen Elemente des Datenmoduls im Code, aber behalte ansonsten das TDataModule bei. Ein TDataModule benötigt kein Designformular, wenn man den Designer nicht verwenden möchte (TForm übrigens auch nicht).charlytango hat geschrieben: ↑Mo 19. Dez 2022, 18:32angenommen es gibt ein komplexes Datenmodul (samt lfm-file) und ich möchte dieses in einer eigenen Unit so umschreiben dass kein LFM File mehr nötig ist, so kann ich das indem ich eine Klasse erstelle und in dieser die Creates und Destroys samt Einstellungen mache. Soweit so gut.
Weitgehend existiert dann also gleicher Code doppelt, was ich nicht so mag und fehleranfällig ist.
Gibt es irgend eine Schreib-Technik die es mir erlaubt den Code für beide Fälle, also das Datenmodul und die Unit anzubieten und den Code nur einmal zu haben?
Da ist nichts magisches dabei, sondern einfach eine Anwendung von $Define und $Undef. Schau dir die Unit an, in der die von dir zitierte Includedatei genutzt wird, dann kannst du sehen wie es funktioniert.charlytango hat geschrieben: ↑Mo 19. Dez 2022, 21:23mittlerweile bin ich mit der Recherche etwas weiter.
Bei FPC werden ausgiebig Include Files verwendet.
So ein File sieht zB so aus:
Es scheint also mit read_interface und read_implementation eine Funktionalität zugeben um aus einem einzigen Includefile Interfaceteil und Implementation zusammen zu setzen. Vermutlich auch noch irgendwie intelligent eingefügt.Code: Alles auswählen
{$IfDef read_interface} type TGConfError = (GCONF_ERROR_SUCCESS := 0,GCONF_ERROR_FAILED := 1, GCONF_ERROR_NO_SERVER := 2,GCONF_ERROR_NO_PERMISSION := 3, GCONF_ERROR_BAD_ADDRESS := 4,GCONF_ERROR_BAD_KEY := 5, function gconf_error_quark:TGQuark;cdecl;external gconfdll name 'gconf_error_quark'; function GCONF_ERROR : TGConfError; {$EndIf read_interface} {$Ifdef read_implementation} function GCONF_ERROR : TGConfError; begin GCONF_ERROR := TGConfError(gconf_error_quark); end; {$Endif read_implementation}
Kennt jemand dazu irgendwo eine Doku?
FPC Compiler Entwickler
- fliegermichl
- Lazarusforum e. V.
- Beiträge: 1432
- Registriert: Do 9. Jun 2011, 09:42
- OS, Lazarus, FPC: Lazarus Fixes FPC Stable
- CPU-Target: 32/64Bit
- Wohnort: Echzell
Re: Wiederverwendbarkeit von Code
Ich hatte mich gefragt, wozu das Gehampel mit read_interface und read_imlementation gut sein soll.
Es ist so, daß z.B. die Datei messages.inc von mehreren Units eingebunden wird (gtk1, gtk2, win, wince etc.)
Dabei wird die Datei jeweils im interface als auch im implementation Teil der Unit per {$i messages.inc} eingebunden.
jetzt wird im interface Teil angegeben
{$define read_interface}
{$undef read_implementation}
{$i messages.inc}
im implementation Teil ist es eben umgekehrt.
Es ist so, daß z.B. die Datei messages.inc von mehreren Units eingebunden wird (gtk1, gtk2, win, wince etc.)
Dabei wird die Datei jeweils im interface als auch im implementation Teil der Unit per {$i messages.inc} eingebunden.
jetzt wird im interface Teil angegeben
{$define read_interface}
{$undef read_implementation}
{$i messages.inc}
im implementation Teil ist es eben umgekehrt.
-
- Beiträge: 843
- Registriert: Sa 12. Sep 2015, 12:10
- OS, Lazarus, FPC: Laz stable (2.2.6, 3.x)
- CPU-Target: Win 32/64, Linux64
- Wohnort: Wien
Re: Wiederverwendbarkeit von Code
ok, ich habe das nun getestet und erstaunlicherweise ist die Unterstützung der GUI bemerkenswert.
Ja, das Einbinden von Code per Include und Defines funktioniert.
Auch gestaffelt und ineinander.
Trotzdem ist es für mich doch sehr unübersichtlich und unbequemer als eine einzige Datei.
Danke an alle Beteiligten
Ja, das Einbinden von Code per Include und Defines funktioniert.
Auch gestaffelt und ineinander.
Trotzdem ist es für mich doch sehr unübersichtlich und unbequemer als eine einzige Datei.
Danke an alle Beteiligten
- fliegermichl
- Lazarusforum e. V.
- Beiträge: 1432
- Registriert: Do 9. Jun 2011, 09:42
- OS, Lazarus, FPC: Lazarus Fixes FPC Stable
- CPU-Target: 32/64Bit
- Wohnort: Echzell
Re: [Erledigt] Wiederverwendbarkeit von Code
Wobei Lazarus eine sehr gute Unterstützung hierfür hat.
Nehmen wir mal als Beispiel eine Unit, welche verschiedene (betriebssystemabhängige) API's unterstützen soll, aber für den Lazarus Programmierer eine einheitliche Schnittstelle bieten soll.
Dann kann ich den Plattform abhängigen Code in einzelne IncludeFiles auslagern.
Stelle ich jetzt das Caret auf die Zeile im Interface Teil und drücke Ctrl+Shift+Cursor runter, dann lädt Lazarus automatisch die richtige Include Datei und springt an die Stelle der Implementation der procedure.
Nehmen wir mal als Beispiel eine Unit, welche verschiedene (betriebssystemabhängige) API's unterstützen soll, aber für den Lazarus Programmierer eine einheitliche Schnittstelle bieten soll.
Dann kann ich den Plattform abhängigen Code in einzelne IncludeFiles auslagern.
Code: Alles auswählen
unit xyz;
interface
procedure DrawSomeWhat(Canvas : TCanvas);
implementation
{$ifdef linux}
{$i linux/draw.inc}
{$endif}
{$ifdef windows}
{$i win/draw.inc}
{$endif}
end.