Namespaces unter Delphi 10 Rio

[Delbor]

Hi zusammen

Nachdem ich nun alle Fremdkomponenten im Anschluss an diesen Thread installiert habe und die Dinger auch in der (Tool-)Palette aufgeführt sind, wollte ich das auch testen. Ich hab also auf eines der Beispielprogramme mal eine TOcr-Komponente gepackt und F9 gedrückt. Resultat: 1 Feher. Angemeckert wurde die Unit Ocr, die der Compiler nicht finden konnte.

Mit allen anderen Fremdkomponenten wars genau dasselbe, einschliesslich der TFilesearcher-Komponte, von der ich aus früheren Versionen (auch Tokio) weiss, dass sie sich Problemlos neu compilieren lässt, bzw. auch ohne diese installiert werden kann.

Such- und Bibliothekspfad sollte soweit in Ordnung sein, also hab ich mich mal versucht, zu Namespaces schlau zu machen. Soweit ich das richtig verstanden habe, muss ich dem Unitnamen den gewünschten Namespace-Namen voranstellen, bevor ich sie zusammen mit diesem speichere.
Hab ich das richtig verstanden?
Oder muss ein eigener Namespace speziell deklariert werden?

Gruss
Delbor

[jaenicke]

Man muss in eigenen Units keine Namespaces nutzen. Es macht aus Gründen der Übersichtlichkeit natürlich Sinn, ist aber keine Pflicht.

Lediglich bei bestehenden Namespaces in Units, z.B. beim Zugriff auf VCL- und RTL-Units, muss man den Namespace entweder in den Projektoptionen hinterlegen oder an jeder Unit in der uses-Klausel angeben.

Wenn der Compiler also eine Unit nicht finden kann, liegt die .dcu nicht im Bibliothekspfad. Mit Hilfe des Process Monitors kann man auch leicht prüfen wo gesucht wird. Ein beliebter Fehler ist den 64-Bit Bibliothekspfad statt den für 32-Bit zu setzen.

[Delbor]

Hi jaenicke

Zitat von jaenicke:

Wenn der Compiler also eine Unit nicht finden kann, liegt die .dcu nicht im Bibliothekspfad. Mit Hilfe des Process Monitors kann man auch leicht prüfen wo gesucht wird. Ein beliebter Fehler ist den 64-Bit Bibliothekspfad statt den für 32-Bit zu setzen.

Vielen Dank für deine Antwort! Tatsächlich konnte ich mir die Frage, welche Datei wohin gehört(dcu, pas oder was) nicht endeutig beantworten.
In den letzten Wochen hab ich mir angewöhnt, für alle Projekte nebst dem Debug- auch ein DCU-Verzeichnis anzulegen. Du hattest mal davon gesprochen, dass ihr einen eigenen zentralen Dcu-Pfad benützt. Ich denke, dass sollte ich beherzigen.
Angelegt hab ich mir sowas zwar, hatte dann aber bedenken, dass es nicht so einfach sein könnte, da nur die DCUs eines bestimmten Projektes zu löschen, Tja, man kann auch verkehrt denken...

Gruss
Delbor

PS:

Zitat:

Lediglich bei bestehenden Namespaces in Units, z.B. beim Zugriff auf VCL- und RTL-Units,

Bei einer der Fremdkomponenten wurde die Unit Graphics als nicht gefunden angemeckert - ein VCL. davor, und gut war.

[jaenicke]

Zitat von Delbor:

Angelegt hab ich mir sowas zwar, hatte dann aber bedenken, dass es nicht so einfach sein könnte, da nur die DCUs eines bestimmten Projektes zu löschen, Tja, man kann auch verkehrt denken...

Wir haben ein .dcu Verzeichnis für unsere Packages, so dass gemeinsame Units nur in einem Pfad gesucht werden müssen. Daher ist der auch fast der einzige Pfad, der im globalen Bibliothekspfad drin steht.

Dazu haben wir dann ein zweites Verzeichnis, in das die diversen Projekte, jeweils in einem eigenen Unterordner und darin nach Plattform und Debugkonfiguration getrennt, ihre .dcu Dateien ablegen. Denn die werden ja nur innerhalb des Projekts benötigt.

Der Effekt ist, dass gemeinsame Units zentral in Packages kompiliert und von allen Projekten gefunden werden. Diese Units werden auch nicht in die verschiedenen Projekte eingebunden. Die Units der einzelnen Projekte wiederum behindern sich gegenseitig auch nicht, denn diese kompilieren ja immer in verschiedene Verzeichnisse. Und wie du schon sagtest, man kann so die .dcu Dateien eines Projektes leicht löschen.

Wir können aber auch alle .dcu Dateien, auch die im Bibliothekspfad, löschen und dann einfach per Batchdatei wieder erstellen lassen. Die Batchdatei kopiert die .res Dateien usw., die eingebunden werden, in den Bibliothekspfad und kompiliert dann mit Hilfe von msbuild die Packages. In der aktuellen Version installiert es auch die Packages, so dass die Installation nun sehr einfach ist:
Delphi installieren, JEDIs installieren, install.cmd ausführen
Es werden auch die Einstellungen von Delphi und den CnWizards direkt gesetzt.

[Delbor]

Hi jaenicke

So, wie's jetzt aussieht, gibts wohl etwas mehr Arbeit für mich - ich hab das eine Package-Projekt geöffnet, da den DCU-Pfad geändert und neu compiliert. Allerdings habe ich die Komponenten nicht deinstalliert, und so ist eigentlich alles beim alten geblieben. Das heisst für mich eigentlich: Neu anfangen.
Wobei ich mir auch nicht sicher bin, nicht von Anfang an einen Fehler gemacht zu haben: Statt <Komponente/Komponente installieren> habe ich über die Objectablage ein neues Package erstellt und da die Komponenten reingepackt. Auch möglich, dass dsa nicht explizit falsch ist, nur sollte ich über <Komponente/Komponente installieren> mehr Möglichkeiten haben.

Gruss
Delbor

[jaenicke]

Zitat von Delbor:

Wobei ich mir auch nicht sicher bin, nicht von Anfang an einen Fehler gemacht zu haben: Statt <Komponente/Komponente installieren> habe ich über die Objectablage ein neues Package erstellt und da die Komponenten reingepackt. Auch möglich, dass dsa nicht explizit falsch ist, nur sollte ich über <Komponente/Komponente installieren> mehr Möglichkeiten haben.

Der Wizard ist eher etwas für Anfänger, weil es relativ umständlich aber dafür einfach ist.
Der Weg über ein ganz normales Package ist schon richtig.

Das Problem ist immer noch die Unit ocr, die in diesem Package drin ist. Wie lauten denn der dcu- und der dcp-Ausgabepfad? Und wie sieht dein Bibliothkspfad aus? Wo liegt die ocr.dcu?

[Delbor]

Hi jaenicke

Zitat von Delbor:

Hi jaenicke
So, wie's jetzt aussieht, gibts wohl etwas mehr Arbeit für mich - ich hab das eine Package-Projekt geöffnet, da den DCU-Pfad geändert und neu compiliert. Allerdings habe ich die Komponenten nicht deinstalliert, und so ist eigentlich alles beim alten geblieben.

Zumindest gehe ich davon aus, dass sich an installierten Komponenten vorrerst nichts ändert, auch wnn das Package neu compiliert wurde.
Die einzelnen Package-Projekte und die Bpls gibts ja noch. Von daher ists wirklich das einfachste, diese zu bearbeiten und neu zu compilieren.

Zitat von Delbor:

Wobei ich mir auch nicht sicher bin, nicht von Anfang an einen Fehler gemacht zu haben: Statt <Komponente/Komponente installieren> habe ich über die Objectablage ein neues Package erstellt und da die Komponenten reingepackt. Auch möglich, dass dsa nicht explizit falsch ist, nur sollte ich über <Komponente/Komponente installieren> mehr Möglichkeiten haben.

Ich denke, ich hätte mit diesem Wizard eine einfache Möglichkeit, alle Komponenten in ein einziges Package zu packen. Wobei es mir allerdings eher darum geht, dass die meisten (der Filesearcher passt thematisch nicht) auf einer einzigen Palettenseite zusammengefasst werden. Aber auch da brauchts den Wizard wohl nicht unbedingt.

Zitat von jaenicke:

Das Problem ist immer noch die Unit ocr, die in diesem Package drin ist. Wie lauten denn der dcu- und der dcp-Ausgabepfad? Und wie sieht dein Bibliothkspfad aus? Wo liegt die ocr.dcu?

Wie ich festgestellt habe, war das nicht das einzige Problem. Ich habe nacheinander jeweils eine dieser Komponenten auf das Beispielprogramm gesetzt; deren Units wurden alle als nicht auffindbar angemeckert.
Die OCR liegt hier: F:\Embarcadero Erweiterungs-Corner\DCU. Diesen Pfad hab ich angegeben, bevor ich neu kompilierte. Diese Unit sollte also gefunden werden, wenn ich wieder neu installiere.
Bei den andern Fremdkomponenten muss ich die Pfade noch anpassen.

Gruss
Delbor

[jaenicke]

Zitat von Delbor:

Ich denke, ich hätte mit diesem Wizard eine einfache Möglichkeit, alle Komponenten in ein einziges Package zu packen. Wobei es mir allerdings eher darum geht, dass die meisten (der Filesearcher passt thematisch nicht) auf einer einzigen Palettenseite zusammengefasst werden. Aber auch da brauchts den Wizard wohl nicht unbedingt.

Die Palettenseite legst du ja in der Register Prozedur der Komponente fest. Und alle in ein Package geht ja nun sehr viel einfacher, wenn du die Units per Drag-and-Drop in das Package ziehst, als jedesmal den Wizard zu durchlaufen...

[Delbor]

Hi jaenicke

Zitat von jaenicke:

Die Palettenseite legst du ja in der Register Prozedur der Komponente fest. Und alle in ein Package geht ja nun sehr viel einfacher, wenn du die Units per Drag-and-Drop in das Package ziehst, als jedesmal den Wizard zu durchlaufen...

Upps! Klar, das mit der Palettenseite stimmt, und ich hatte mir das auch vorgenommen. Aber irgendwie gings schlicht vergessen...
Und die Sache mit dem Drag&Drop - da hätte ich auch selbst draufkommen müssen.
Die DCUs liegen jeweils zusätzlich zum Verzeichnis'Debug' im Ordner der jeweilge Komponente, während die dcps in dem unter Tools/Optionen festgelegte Ordner liegen.


Gruss
Delbor

[Delbor]

Hi zusammen

Zitat von jaenicke:

Das Problem ist immer noch die Unit ocr, die in diesem Package drin ist. Wie lauten denn der dcu- und der dcp-Ausgabepfad? Und wie sieht dein Bibliothkspfad aus? Wo liegt die ocr.dcu?

Hmm... Ich hab mich in den letzten Tagen ziemlich durch das Embbarcadero-Wicki gewühlt, unter anderem auch zum Thema Namespaces.
Zitat daraus:

Zitat:

Eine Unit ohne expliziten Namespace wird als generische Unit bezeichnet. Eine generische Unit ist automatisch ein Element des Projekt-Standard-Namespace. Ausgehend von der obigen Program-Deklaration veranlasst die folgende Unit-Deklaration, dass der Compiler MyUnit als Element des Namespace MyCompany.Programs behandelt:

unit MyUnit;

Der Projekt-Standard-Namespace hat bei generischen Units keinen Einfluss auf den Namen der Delphi-Quelldatei. Ausgehend von obiger Deklaration würde dieser Name MyUnit.pas lauten. Dieselbe Regel gilt für den Namen der dcu-Datei. Die resultierende dcu-Datei würde für das aktuelle Beispiel MyUnit.dcu heißen.

Das verstehe ich nun so, dass die generische Unit Ocr, sobald sie im Package unter Contains eingebunden wird, zum Projekt-Standard-Namespace des Packages gehört - und da gibt es sie eben nicht. Das heisst für mich: Ich muss herausfinden, wie der Projekt-Standard-Namespace dieser Unit heisst oder sie mit einem eigenen Namespace abspeichern.
Das würde bedeuten, dass ich die Sourcen der Komponenten neu mit einem Namespace speichern und die Komponente neu kompilieren muss.
Hat da jemand andere Erfahrungen?

Gruss
Delbor