Eine eigene LIBRARY anlegen

[Lorca]

Hallo zusammen,

ich würde gerne eine eigene LIBRARY anlegen um dort einige Klassen abzulegen.
Diese neue LIBRARY würde ich dann gerne mit {$R xxx.RES} bzw. mit LoadLibrary ins Hauptprogramm einbinden / hochladen

Nun gibt es jedoch unter Datei / Neu ... keinen Eintrag für LIBRARY. Also habe ich eine Unit genommen und dann das Schlüsselwort von UNIT in LIBRARY geändert. Das funzt aber nicht. Der Compiler mekkert

Im I-Net habe ich dann gelesen das ich hierzu ein Package anlegen soll.

Nun meine Frage:
Geht es auch ohne Package?
Wie gesagt, ich will diese dann z.B. abhängig von der Programmversion des Hauptprogramms einbinden und nicht etwa über die Component Palette im Designer einbinden.

Kann mir jemand dazu etwas sagen?


Gruß
Lorca

[theo]

Datei -> Neu -> Projekt -> Bibliothek
gibt es bei dir nicht?

[af0815]

ich würde gerne eine eigene LIBRARY anlegen um dort einige Klassen abzulegen.

Weisst du genau warum du das so machen willst oder willst du nur Struktur in den Source bringen ?

Das kennst du https://wiki.freepascal.org/Lazarus/FPC_Libraries ?

[Lorca]

Hallo Theo,

SRY, ja.
Habe ich noch nie drauf geachtet, weil ich immer nur Anwendungen aus diesem Menü angelegt habe.

Nun habe ich das Problem: wie spreche ich die Klasse in meinem Hauptprogramm an???????????

Mit {$R} lässt sich die Library nicht ins Hauptprogramm einbinden. Schade.
Mit LoadLibrary wird mir das Handle zurück gegeben. Mit Handles habe ich jedoch so gut wie keine Erfahrung.
Was muss ich tun, um die exportierte Variable LIB_Band bzw. die Funktion Create_Lib_Band im Hauptprogramm ansprechen zu können?

Die Funktion GetProcedureAddress liefert einen Pointer zurück. Ein Casting auf eine Funktion mit Function( xxx ) funzt nicht.
Gibt es irgendwo Beispiele?

Gruß
Lorca

Hier mal die Library:
LIBRARY MC_LIB_Band;
{$mode objfpc}{$H+}
USES
Classes
;


TYPE
TCL_MC_Band = CLASS( TObject )
PRIVATE
PROTECTED
PUBLIC
CONSTRUCTOR Create; VIRTUAL;
DESTRUCTOR Destroy; OVERRIDE;
END ;

VAR
LIB_Band : TCL_MC_Band;

CONSTRUCTOR TCL_MC_Band.Create;
BEGIN
INHERITED Create;
END;

DESTRUCTOR TCL_MC_Band.Destroy;
BEGIN
INHERITED Destroy;
END;

FUNCTION Create_Lib_Band : TCL_MC_Band;
BEGIN
LIB_Band := TCL_MC_Band.Create;
Result := LIB_Band;
END;


EXPORTS
LIB_Band,
Create_Lib_Band;

END.

[fliegermichl]

Klassen kann man nicht aus Bibliotheken in das Programm exportieren. Für jede Klasse wird eine Virtual Method Table angelegt und zwar getrennt in der Bibliothek als auch im Programm an sich.

Du kannst natürlich in deiner Bibliothek Klassen verwenden und für die Schnittstellen zum Programm einfache Datentypen (aber auch Records) oder Zeiger darauf exportieren.

[charlytango]

Nun meine Frage:
Geht es auch ohne Package?
Wie gesagt, ich will diese dann z.B. abhängig von der Programmversion des Hauptprogramms einbinden und nicht etwa über die Component Palette im Designer einbinden.

Ich habe es immer als Vorteil angesehen, Codeteile (füher)in Delphi und (jetzt) in Lazarus sehr einfach strukturieren und wiederverwenden zu können OHNE irgend ein Gefrickel mit Libraries (also DLLs So und wie sie alle heißen)

Ich strukturiere (wohl wie alle hier) Codeteile (also quasi lose Prozeduren und Funktionen) sowie Klassen je nach Verwendungszweck oder Thema in Dateien (die heissen bei Lazarus eben units). Programmübergreifende Units liegen bei mir in einer übergeordneten Verzeichnisstruktur (heisst bei mir sinnigerweise _shared) und ich binde sie je nach Notwendigkeit einzeln über die uses-Klausel ein das jeweilige Programm ein.
Fertig -- keine Bibliotheken, keine Installation von DLLs und Konsorten.

Weisst du genau warum du das so machen willst oder willst du nur Struktur in den Source bringen ?

Die Frage von af0815 zielte IMHO genau darauf hin ab, genauer heraus zu bekommen WARUM genau du so ein Konstrukt verwenden möchtest, bevor wieder mal Kanonen geladen werden um auf arme Spatzen loszugehen

Sollte deine Absicht sein etwas mehr Struktur in deinen Code zu bringen empfehle ich die Variante mit den Units, denn ich sehe keinerlei Vorteil darin Source nicht direkt ins Programm zu kompilieren wenn der Code ohnedies als Unit vorliegt.

[Lorca]

Hi zusammen,

zunächst einmal danke schön für eure Antworten.
Nun ja, somit ist meine Idee mit Library's erst ein mal vom Tisch.

Also warum ich diese Idee hatte (mit dem Hintergrund das ich Lazarus noch nicht völlig überblicke ).

Ich schreibe derzeit ein Programm mit vielen Registerkarten und sehr, sehr vielen Feldern und Buttons, auf jedem dieser TabSheets.
Meine Idee war nun, für jede Registerkarte eine Library anzulegen welche dann das jeweilige TabSheet behandelt. (Speichern, Ändern etc. PP)

Einbinden wollte ich dann diese Lib Dynamisch. Für das Statische Einbinden wollte ich nur das "KnowHow".

Der Vorteil Vorteil: Dieses Dinger sind kompiliert und lauffähig. Da ich noch in der Entwicklungsphase bin, kann sich durchaus noch einiges an den Klassen ändern. In einem solchen Fall ist das Programm jedoch für jede dieser Registerkarten mit fertiger DLL lauffähig.

Wie war doch gleich das Motto? Write Once, Compile Anywhere

Einen Einwand, gegen den Einsatz einer DLL, halte ich persönlich für Unsinn. Diese Dinger sind austauschbar und im falle von Upgrades sehr nützlich und zeitsparend. Es muß nicht immer das gesamte Coding compiliert und getestet werden.

Schade das die Weiterentwicklung der Librarys stoppt und keine Klassen exportiert werden können.

Viele Grüße
Lorca

[af0815]

So wie du es schreibst, ist für mich ein Thema für Frames.

Wenn man ein Konzept für dynamische Frames sich zugelegt, so will man es nicht mehr missen. Ich entwickle sehr viel mit Frames und verwende die gerne. Oft habe ich Frames in Frames in Frames. Für Datenanzeigen oft ganze Framesarrays

Einmal entwickeln und gut testen, dann nur mehr verwenden.

Klingt Oberlehrerhaft: Man sollte die Konzepte verstehen, die man verwenden will.

Dein Beispiel weiter oben macht mit Frames keinen Sinn. Da gibt nichts visuelles.

[wp_xyz]

Ich schreibe derzeit ein Programm mit vielen Registerkarten und sehr, sehr vielen Feldern und Buttons, auf jedem dieser TabSheets.
Meine Idee war nun, für jede Registerkarte eine Library anzulegen welche dann das jeweilige TabSheet behandelt. (Speichern, Ändern etc. PP)

Wie af0815 schon sagte: das ist eine typische Anwendung von Frames: du erzeugst einen Frame für jedes TabSheet und fügst dann zur Laufzeit den Frame in den entsprechenden Tab ein. Alle Controls auf einem Frame sind dann in ihrer eigenen Unit und sauber getrennt, und diese Details kontaminieren nicht das Hauptformular.

Ein relativ umfangreiches Beispiel mit Frames ist das ChartEditor-Demo im Ordner components/tachart/demo/charteditor der Lazarus-Installation (seit, ich glaube, v2.0).

[m.fuchs]

Schade das die Weiterentwicklung der Librarys stoppt und keine Klassen exportiert werden können.

Da ist keine Weiterentwicklung gestoppt, es war schlicht und einfach niemals vorgesehen im Konzept DLL.
Da die Umsetzung von Objektorientierung in so vielen Sprachen ganz unterschiedlich ist, sehe ich hier auch kaum eine Möglichkeit so etwas auf einfachem Wege umzusetzen.

[PascalDragon]

Ich schreibe derzeit ein Programm mit vielen Registerkarten und sehr, sehr vielen Feldern und Buttons, auf jedem dieser TabSheets.
Meine Idee war nun, für jede Registerkarte eine Library anzulegen welche dann das jeweilige TabSheet behandelt. (Speichern, Ändern etc. PP)

Einbinden wollte ich dann diese Lib Dynamisch. Für das Statische Einbinden wollte ich nur das "KnowHow".

Der Vorteil Vorteil: Dieses Dinger sind kompiliert und lauffähig. Da ich noch in der Entwicklungsphase bin, kann sich durchaus noch einiges an den Klassen ändern. In einem solchen Fall ist das Programm jedoch für jede dieser Registerkarten mit fertiger DLL lauffähig.

Nein, so etwas wäre einfach nur mit zu vielen Problemen behaftet. Ordinäre Bibliotheken ermöglichen einfach nur prozeduralen Zugriff, alles andere ist einfach nur viel Heckmeck und Ärger für die Zukunft.

Schade das die Weiterentwicklung der Librarys stoppt und keine Klassen exportiert werden können.

Das ist eben all das, was mit ordinären Bibliotheken sicher erreicht werden kann.

Wenn FPC in Zukunft mal Dynamische Pakete unterstützt (in Entwicklung, aber fehlt noch ein bisschen was), dann kannst du Klassen auslagern, allerdings hat das zur Folge, dass auch die komplette RTL, FCL und LCL als Paket vorliegen muss (du kannst also nicht selektiv nur einzelne Teile auslagern, weil wir dann wieder an dem Punkt sind, dass dies so einfach nicht machbar ist).

[Lorca]

Hi zusammen,

coole Diskussion. Danke für eure Ideen und Kommentare.

Ja mit den Frames (und auch Frames in Frames) habe ich es versucht und auch reichlich Probleme gehabt.
Daher habe ich dieses Vorgehen erst einmal beiseite geschoben und bin dann auf die Idee mit den DLL's gekommen.
Nun muss ich mich doch durch die Probleme mit den Frames durch beißen.

Das Beispiel von wp_xyz werde ich mir mal reinziehen . (Danke dafür)
Und nein, ich finde hier ist niemand "Oberlehrerhaft"

Was ich bei den Frames nicht so toll finde, ist die Tatsache das die eingebundenen SUB-Frames und alle anderen platzierten Komponenten nicht gekapselt sind. Also überall Verfügbar.
Vllt. schlaut mich ja das Beispiel ein wenig auf,


Viele Grüße
Lorca

[af0815]

Was ich bei den Frames nicht so toll finde, ist die Tatsache das die eingebundenen SUB-Frames und alle anderen platzierten Komponenten nicht gekapselt sind. Also überall Verfügbar.
Vllt. schlaut mich ja das Beispiel ein wenig auf,

Grafische Komponenten kann man per se nicht Kapseln, solange man die IDE zum editieren verwendet. Ganz streng Kapseln kann man nur dann etwas, wenn man es zur Laufzeit erzeugt, das aber dann komplett.

Wenn ich Frames verwende, sehe ich die SubFrames nicht, weil diese auch wieder zur Laufzeit erzeugt werden. Die Komponneten bleiben natürlich sichtbar. Das spielt mir aber keine Rolle. Ich gereife nur über Schnittstelle zu und verwende Callbacks, wenn das Frame dem Elternteil etwas mitteilen muss/will. Ich weise den Komponenten im Frame niemals was direkt zu. Ich teste das mit einem speziellen Programm wo ich mein FrameUnderTest aufrufe und nur die Schnittstellen und Callbacks bediene. Damit kann ich das Verhalten austesten und auch die Schnittstellen. In der fertigen Applikation wird das ganze genauso hineingehängt. Wenn ich einen Fehler suche, dann verwende ich wieder das spezielle Programm und kann dort die Schnittstellen mit vermutlich Fehlerauslösenden Werten befüllen. Damit kann man sehr stabile Frames haben, die man bedenkenlos in verschiedenen Projekten verwenden kann. Allerdings, wenn ein Frame dann anderes reagieren soll, so muss man ein neues Frame machen, da sonst andere Programme/Projekte beeinflusst werden. Das darf man niemals vergessen, wenn man mit so Baukästen arbeitet. Ansonsten kommt man in die Versionshölle.