eigene Komponenten und deren Verwaltung in Packages

[BAMatze]

Hallo und nochmal Guten Morgen an alle DP´ler,

nach meiner doch etwas spezifischen Frage bei einem Problem für das Einbinden von Komponenten in Delphi habe ich jetzt eigentlich eine eher prakmatische Frage an euch und die die damit etwas mehr Erfahrung haben. Also auch wenn ich das am Anfang gar nicht so geglaubt hab, weil ich die Erstellung von spezifischen Komponenten für die eigenen Zwecke eher für langweilig gehalten habe, merke ich jetzt doch, dass es sehr hilfreich und teilweise notwendig ist.
Mein Problem jetzt ist eigentlich, wie verwalte ich das ganze am besten. Ich hab zwar noch nicht sehr viele Komponenten erstellt aber aus anderen Bereichen weiß ich, wenn man da nicht möglichst schnell Ordnung rein bringt, versickt man bald im Chaos. Deswegen jetzt mal an die die damit sehr viel Erfahrung haben die Frage, wie verwaltet ihr eure Komponenten?? Bei mir hat bis jetzt eigentlich jede Komponente ein eigenes Package (ich denke mal das ist schon der erste unsinnige Ansatz) und liegt unter Samples bei den Tools. Da ich wie man auch an der Post davor merkt noch nicht wirklich viel damit zu tun hatte. Damit bin ich aber sicherlich offen für Vorschläge oder Verbesserungen.

Vielen Dank
BAMatze

[oki]

Hi,

für alle meine eigenen allgemeinen Komponenten lege ich eine eigene "Lasche" wie etwa "okiCompos" an. Alle diese Komponenen liegen dann mit ihren Units in einem gemeinsamen Package. Dabei habe ich es mir angewöhnt die Registrierung der Komponenten des Packages in einer seperaten Unit auszulagern. Somit hat man den Besten Überblick im Code welche Kompos man registriert. Sollte es Sinn machen hier spezifische "Laschen" nachträglich anzulegen und sozusagen die Zuordnung der Komponenten zu ändern, ist alles viel übersichtlicher. Ein weiterer Vorteil ist, dass man so schnell das Package in Runtime- und Designtime-Package auftrennen kann.

Für projektbezogene Komponenten lege ich in der Regel seperate Packages an, da diese Komponenten oft sehr speziell und weniger für den allgemeinen Gebrauch geeignet sind. Dieser bekommen dann auch eine eigene Lasche.

Ja, so siehts bei mir aus.

Gruß oki

[BAMatze]

Auch wenn das jetzt etwas vermessen klingt vieleicht, hast du da mal so eine art Dummy-Package mit 2 oder 3 einfachen Komponenten (sollen ja keine spezifischen sein) wo man sich das mal vom Quellcode, Units in der Package bis hin zur registrierten Komponente in Delphi mal ansehen kann? Es würde mich einfach mal interessieren, wie sowas dann aussieht. Ist aber auch ok, wenn das nicht geht.

[Optiplex]

Oki deine Art der Komponentenverwaltung ist sehr ausgereift und Ok, ich mache das in der Regel genauso, aber ich habe festgestellt, dass man mit Änderungen in den eigenen Komps sehr sorgfälltig umgehen muss, so passiert es mit immer wieder, dass ich nachträglich etwas ändere und dann in einem alten Projekt beim Laden Fehlermeldungen auftreten weil ich einen Property geändert oder gelöscht habe.

Vielleicht hast du dafür auch eine Lösung perat.

Gruss Dieter

[oki]

Zitat von Optiplex:

Oki deine Art der Komponentenverwaltung ist sehr ausgereift und Ok, ich mache das in der Regel genauso, aber ich habe festgestellt, dass man mit Änderungen in den eigenen Komps sehr sorgfälltig umgehen muss, so passiert es mit immer wieder, dass ich nachträglich etwas ändere und dann in einem alten Projekt beim Laden Fehlermeldungen auftreten weil ich einen Property geändert oder gelöscht habe.

Vielleicht hast du dafür auch eine Lösung perat.

Gruss Dieter

Jo, das ist ein Problem, mit dem ich auch immer wieder kämpfe. Ich denke aber, dass das für die übersichtliche Gestaltung (Anordnung) der Komponenten unerheblich ist. Ändere ich im Code einer Komponente etwas, dann ist es egal, ob das in einem kleinen oder großen Package erfolgt.
Die einzige Lösung hier ist nur die Vererbung. Ich habe festgestellt, dass ich manchmal für eine spezielle Sache eigentlich eine vorhandene eigene Kompo gut einsetzen kann, diese aber an einer entscheidenden Stelle ändern muss. Dann kommt wirklich die Angst bezüglich alter (anderer Projekte). Um das zu umgehen lege ich dann in der Regel einen speziellen Nachfahren an. Das alte Projekt wird nicht durch die Änderungen berührt und das neu nutzt die neue Kompo. Klappt aber nicht immer so gut, vorallem wenn man einen grundlegenden Fehler oder Fehlentscheidung korrigieren muss.
Eigentlich lege ich immer mehrere Klassen für eine Komponente an. Als erstes eine BaseCompo, die die allgemeinen Grundfunktionen enthält. Dann eine spezialisierte Klasse und manchmal danach auch noch eine die nur die Propertys veröffentlicht (stirbt oft aus Faulheit ).

Die Frage war aber wohl nach der Organisation.

@BAMatze: Beispiel ist eher schwer. Aber mal grob ein Aufbau:

Package: MyPackage_D.bpl (Designzeit-Package)
enthält die Unit: RegisterMyComponents.pas in "Entkält"
in Benötigt: MyPackage_R.bpl

Package: MyPackage_R.bpl (Runtime-Package)
enthält alle Units in denen der Quellcode der Komponenten steht. (MyCompo_A.pas, MyCompo_B.pas ....)
in Benötigt sind alle Packages aufgeführt, in denen _Units enthalten sind, die benutzt werden (nicht in Enthalten mit aufführen!!).

Da in MyPackage_D.bpl nur eine Unit liegt (wenn nicht mehrere Sinn machen) ist das für die Registrierung in der IDE sehr übersichtlich.
Die Unit enthält dann in Uses alle Units des Packages MyPackage_R.bpl und die procedure Register.

Delphi-Quellcode:

procedure Register;
begin
  RegisterComponents['OKI_VCL_Compos', [TMyCompoA, TMyCompoB]);
  RegisterComponents['OKI_nonVCL_Compos', [TMyCompoC, TMyCompoD]);
end;

Ob das jetzt der Stein der Weisen ist, kann ich nicht sagen. Das ist mein aktueller Stand und eher aus Erfahrungen gewachsen (an der einen oder anderen Stelle sicher auch abgeschaut ).

Gruß oki

[BAMatze]

Zitat von oki:

@BAMatze: Beispiel ist eher schwer. Aber mal grob ein Aufbau:

Package: MyPackage_D.bpl (Designzeit-Package)
enthält die Unit: RegisterMyComponents.pas in "Entkält"
in Benötigt: MyPackage_R.bpl

Package: MyPackage_R.bpl (Runtime-Package)
enthält alle Units in denen der Quellcode der Komponenten steht. (MyCompo_A.pas, MyCompo_B.pas ....)
in Benötigt sind alle Packages aufgeführt, in denen _Units enthalten sind, die benutzt werden (nicht in Enthalten mit aufführen!!).

Da in MyPackage_D.bpl nur eine Unit liegt (wenn nicht mehrere Sinn machen) ist das für die Registrierung in der IDE sehr übersichtlich.
Die Unit enthält dann in Uses alle Units des Packages MyPackage_R.bpl und die procedure Register.
Gruß oki

Hmm also denke den groben aufbau hab ich jetzt verstanden, wobei ich eins noch nicht so überblicke. Ich weißnatürlich, was Runtime und Designzeit bedeuten, aber derzeit mache ich da nicht so die Unterschiede, kannst du da mal etwas drauf eingehen? Vieleicht steckt darin ja die Lösung für eins meiner Probleme die ich hier gepostet hab, nur leider noch keine Antwort bekommen.

[oki]

[quote]
Ich weißnatürlich, was Runtime und Designzeit bedeuten, aber derzeit mache ich da nicht so die Unterschiede, kannst du da mal etwas drauf eingehen? Vieleicht steckt darin ja die Lösung für eins meiner Probleme die ich hier gepostet hab, nur leider noch keine Antwort bekommen.
[delphi]
Grundsätzlich brauchst du die Trennung eher selten. Der Vorteil entsteht imho an zwei Stellen:
1. solltest du ein Programm schreiben, dass Runtimepackages verwendet, so brauchst du nur diese weitergeben.
2. Bindest du eine Unit des ersten Packages in dein neues Package ein (aber nur in Benötigt und über das Package; Name der Unit in Uses der verwendenden unit angeben), so ist der ganze "Registrierungskram" nicht enthalten, da du ja die Units über das Runtimepackage einbindest und somit dieses keine Registrierungen enthält.

Jetzt zu deinem gelinkten Problem. Ehrlich gesagt habe ich da nicht verstanden. Am Besten, du formulierst deine Frage noch mal neu. Vielleicht hast du deshalb noch keine Antworten erhalten, weil es anderen auch so geht. Ich hab sowohl dein Problem, wie auch das was du getan hast nicht verstanden.

Beispielcode ist sicher auch hilfreich.

Gruß Oki

[Optiplex]

ok BAMatze
ich habe mir deinen Code einmal angeschaut, eigendlich ist mir da nichts besonderes aufgefallen, deshalb kann es nur am Package liegen. Hast du die beiden anderen Komponenten ebenfalls im Package oder sind diese in einem anderen? Hast du sowohl runtime als auch desigtime angehagt und hast du die vcl/rcl mit ins Package genommen. Wenn du das alles hast, dann muss es einfach gehen.

Gruss Dieter

[oki]

Hi Dieter,

schau mal, dass du zum Code in dem entsprechenden Thread antwortest. Ich glaube, hier in diesem Thread geht es wohl eher um Designfragen zu Packages.

Man kommt sonst schnell durcheinander und der Thread wird unverständlich.

Gruß oki

[Optiplex]

Du hast natürlich recht Oki.

Dieter