Zeos 7.2.4 in Tokyo 10.2.3 einbinden, kann mir jemand bitte helfen?

[Stevie]

Delphi sucht beim Kompilieren von Packages für die benötigten Packages, die im

Delphi-Quellcode:

requires

stehen, in seinem DCP Ausgabeverzeichnis (möglicherweise auch in anderen, das weiß ich gerade nicht, weil ich an diesen Pfaden niemals rumfummel) - zu finden in den Umgebungsoptionen.

Wichtig hierbei zu wissen ist, dass DCP Dateien nie den Version suffix haben und die IDE somit sehr wohl mal eine falsche DCP finden kann (von einer anderen Delphi Installation), daher kommt in aller Regel der E2225. Also einfach mal nach entsprechenden Dateien suchen.

[KodeZwerg]

Zitat:

Zitat von Stevie (Beitrag 1402900)

Delphi sucht beim Kompilieren von Packages für die benötigten Packages, die im

Delphi-Quellcode:

requires

stehen, in seinem DCP Ausgabeverzeichnis

Boah, da hätte ich noch Jahre vergebens nach dem Fehler gesucht, das war es!!!:thumb:
Ich hab den DCP Pfad auch abgeändert aber nicht im Library zur Verfügung gestellt, der Fehler wie immer vorm Rechner :wall::wall::wall:

Vielen Dank an alle die geholfen haben, es funktioniert jetzt!!

[MichaelT]

Ich habe die Datei, wir haben sehr wahrscheinlich die selbe/gleiche, in mein c:\lib\zeos Verzeichnis entpackt. Die Project Group geladen und eine Package nach der anderen durchcompiliert und gebuildet. Die letzte eben installier. Dafür braucht man noch keine Pfade resp. den Library Path (IDE) oder Search Path(Projekt) zu den Sourcen zu setzen, gar nichts.

Die Pfade kommen an sich hernach ins Spiel sobald bspw. eine Komponente auf eine Form wird gezogen und im Anschluss kompiliert.

Also vermute ich, danke Steve hatte ich vergessen aber 'eh gemeint', dass die BPLs resp davon abgeleitet die DCPs aus einem Pfad gezogen werden der im Windows Pfad verfügbar ist oder anders bekannt gegeben wurde.

im C:\Users\Public\Documents\Embarcadero\Studio\19.0\ Bpl landeten die BPLs
im C:\Users\Public\Documents\Embarcadero\Studio\19.0\ Dcp landeten die DCPs

(Delphi) Variable BDSCommonDir (c:\Users\Public\ ... )und die kommt im Library Path mit beiden Unterverzeichnissen vor und im Package- als auch im DCP Output directory.

Ich denke die ZEOS Packages wollen mal von Haus aus dort ihre BPLs und DCPs ablegen.


Die DCUs waren bei mir dann im entsprechenden

C:\lib\zeos\packages\DelphiXE10.2\Win32\Debug

zu finden.

Zitat:

Zitat von KodeZwerg (Beitrag 1402896)

Zitat:

Zitat von MichaelT (Beitrag 1402890)

Liegen im C:\Users\Public\Documents\Embarcadero\Studio\19.0\ Bpl noch alte BPLs rum?

Es existiert das Verzeichnis aber ist komplett leer auch dessen Win64 Unterverzeichnis, BPLs liegen bei mir an zwei Orten, das \bin\ <-> \bin64\ da sind die originale von Emba enthalten und ein eigenes \BPL\ Verzeichnis, da kompiliert Delphi neue Packages rein was auch im Library-Pfad angegeben ist, Daniels Startpage funktioniert auch aus diesem \BPL\ Verzeichnis heraus, Uwes PngComponents auch.

Zitat:

Zitat von MichaelT (Beitrag 1402890)

Sind die Files oder die Verzeichnisse aus irgendeinem Grunde readonly gesetzt?

Nein. Delphi darf bei mir schalten und walten, nur nichts ungewolltes aus dem Internet laden, das darf Delphi nicht.

[MichaelT]

Na dann ist es gut.:thumb:

Zitat:

Zitat von KodeZwerg (Beitrag 1402902)

Zitat:

Zitat von Stevie (Beitrag 1402900)

Delphi sucht beim Kompilieren von Packages für die benötigten Packages, die im

Delphi-Quellcode:

requires

stehen, in seinem DCP Ausgabeverzeichnis

Boah, da hätte ich noch Jahre vergebens nach dem Fehler gesucht, das war es!!!:thumb:
Ich hab den DCP Pfad auch abgeändert aber nicht im Library zur Verfügung gestellt, der Fehler wie immer vorm Rechner :wall::wall::wall:

Vielen Dank an alle die geholfen haben!!

[KodeZwerg]

Also kompilieren und einbinden klappt, war halt meine Eigene Schuld das zu übersehen!
Ich geh da nach Anleitung weiter vor bzw. hätte ich es eh so gehandhabt, die DCUs auch im Library Pfad und fertig sollte es sein, wenn da doch noch mal nach einem Source gefragt wird kann ich ja nachreichen.

Vielen Dank an alle für Eure Geduld mit mir!!

[Stevie]

Zitat:

Zitat von Stevie (Beitrag 1402900)

Delphi sucht beim Kompilieren von Packages für die benötigten Packages, die im

Delphi-Quellcode:

requires

stehen, in seinem DCP Ausgabeverzeichnis (möglicherweise auch in anderen, das weiß ich gerade nicht, weil ich an diesen Pfaden niemals rumfummel) - zu finden in den Umgebungsoptionen.

Korrektur: es wird wie Michael richtigerweise erwähnte der Library path verwendet, dort steht standardmäßig auch das standard DCP Ausgabeverzeichnis drin. Ändert man also dieses, muss man auch den Library path anpassen.

[KodeZwerg]

Um ehrlich zu sein, ich las Deinen Text, betrachtete Dein Bild, sah das der DCP auch im Library ist, bei mir gecheckt und boing, das isses gewesen. Danke danke:thumb:

[MichaelT]

Das ist eine lange Geschichte. Früher als der Hauptspeicher sehr knapp (90) war wurde sehr viel Wert drauf gelegt die Komponenten in der GUI (BPL) zu trennen von den gelinkten 'Libraries' (DCP).

In der BPL waren der sichtbar Teil mit dabei (Property Editoren bspw.). In PHP Welt wäre der Teil heute eher ein Smarty Template (auch wenn der Vergleich hinkt).

Im DB Bereich fließt diese Trennung eher im Rahmen der Schichtung (Layering) bei Devart, FireDAC, DBX (stackable drivers bspw.) und ZEOS eher in der Architektur ein.

In einer BPL steht salopp formuliert der Teil noch zusätzlich drinnen der in den Lazarus noch muss reinkompiliert werden. Hernach kann man frisch von der Leber rumpfrimmeln.

---

Borland hat ein wenig vermischt.

An sich gibt es in der 'C' Welt (Pascal fällt schon auch in diese Kategorie ob des PC) Libraries die statisch oder dynamisch gelinkt werden.

---

Ein Modul läuft im Kontext eines geschlossenen Systems (IBM, DEC, Tandem, ...). In moderner Sprache wurden diese Module gejittet. In der Library waren die .obj Files verpackt. COM/MTS, DCOM, COM+ wäre so ähnlich gelagert und verbandelt mit ASP (MS rund um 2k). Ganz zu Beginn von .net war man eigentlich wieder an dem Punkt. (ASP.net Forms und Winforms). Das war der Übergang zu den Assemblies und damit verbunden die Namespaces. Namespaces wäre eine Art Klammerung aus der architektonischen Sicht.

Ein Model wird aktiviert. Bei die ursprünglichen Module (findet man heute noch im Großrechner Modula) wurde angegeben ob bspw. bei jedem Aufruf eine Instanz wird erzeugt. Damit hat sich wieder vermischt bspw. die Vorgabe 'eine Prozedur darf nur ca. eine Bildschirmseite (Terminal) lange sein). 24 + 1 Zeilen (Propertied DOS Promt, Terminal Size Linux bpsw.)

Daraufhin wurden oft einzelne Prozeduren in Module verpackt. Das merkt man noch beim Import Statement import Modul.Funktionsame (bspw.) (ähnlich Java, allein dass Java keine Prozeduren kennt und somit auf jeden Fall mal in dem Kontext ein Modul importiert). Das gab es auch in Java. Klassen mit einer Methode die per HTTP Request wurde aufgerufen. Die Java Welt war die zweite Schiene den Host/Mainframe über CS abzulösen. Bevor J2EE kam.

---

Libraries sind Verbunde von übersetzten Compilation Units. C kennt keine Module. Module kommen mehr oder weniger aus der Mainframe Welt. Der UNIX Ansatz war die Executable.


Ein Package selbst ist Klammerung von Source Code Files. Mehr an sich nicht. Deswegen handelt es sich auch um eine Package Library. Deswegen wird die Package auch gecached. Damit die das RAD Studio schnell nachschauen kann. Das dreht sich für den Programmier um und geht zu seinem Bücherregal wo die gute alte 20m DEC Dokumentation zur PDP 11 steht.

---

Derweil lass dich von DCL und DCPs nicht schrecken. Irgendwann mal vor/rund um 2000 wurde die Trennung aufgegeben. Der Overhead der GUI Repräsentation wurde in Relation zum Hauptspeicherzugewinn immer geringer. Dann, glaube ich, kam erst die Änderung (aber mich nicht schlagen wenn dem nicht so ist), dass die DCPs automatisch gefunden werden sobald die Position der BPL im Filesystem bekannt ist. (Das kann ich nicht mit Sicherheit sagen).

Sauberer ist wie Stevie implizit sagt die Trennung. Heute eher aus dem Gesichtspunkt der Schichtung und der Architektur und nicht mehr einer technisch bedingten Erfordernis geschuldet.

Zitat:

Zitat von KodeZwerg (Beitrag 1402905)

Also kompilieren und einbinden klappt, war halt meine Eigene Schuld das zu übersehen!
Ich geh da nach Anleitung weiter vor bzw. hätte ich es eh so gehandhabt, die DCUs auch im Library Pfad und fertig sollte es sein, wenn da doch noch mal nach einem Source gefragt wird kann ich ja nachreichen.

Vielen Dank an alle für Eure Geduld mit mir!!