Hallo!

Ist es eigentlich mittlerweile möglich, dass man einzelne Rubriken der Toolpalette hinzufügen kann wenn man ein bestimmtes Projekt öffnet?

Konkret geht es mir darum: Wenn ich ein Projekt habe, in dem ich viele selbst erstellte, spezialisierte Komponenten verwende, dann wäre es schick, wenn diese Komponenten in der Toolpalette registriert wären. Dann kann ich sie ganz normal per IDE aufs Formular legen statt in der Runtime zu Fuß zu instantiieren.

Da ich diese speziellen Komponenten aber nur in diesem einen Projekt benötige, wäre es gut wenn die entsprechende Rubrik (Package) nur dann in der Toolpalette erscheint wenn ich das entsprechende Projekt öffne.

Ist sowas inzwischen machbar? Bei D7 ging es ja meines Wissens nicht.

Grüße
Cody

Hi,

das war auch in D7 möglich: einfach bei den installierten Komponenten den Haken entfernen (nur den, nicht die Komponenten), dann werden die Komponenten "unsichtbar", dann das entsprechende Projekt öffnen und die Haken wieder dran machen (falls die fehlen).

GRüße

Jo das ist schon klar Allerdings hatte ich gehofft, es gäbe inzwischen Automatismen die einem die Arbeit abnehmen wenn man ein entsprechendes Projekt öffnet.

vielleicht habe ich das falsch ausgedrückt: Nach dem erstmaligen Einstellen bleibt das auch so... zumindest in meinem Delphi 7...


Grüße

Zitat von Codehunter:

viele selbst erstellte, spezialisierte Komponenten verwende...

Da fängt das Problem schon an.
Komponenten sollten so programmiert werden, dass sie universell einsetzbar sind. (wie die guten alten Legosteine aus den 80ern)
Wenn man Komponenten ganz speziell nur für ein Projekt entwickelt und diese in der IDE installiert tut man sich damit keinen Gefallen.
Das merkt man dann wenn man das Projekt auf einem anderen Rechner kompilieren möchte wieviel Aufwand es bedeutet die ganzen projektspezifischen Komponenten zu synchronisieren und zu installieren.

Ok, bei ein, zwei Komponenten kann man das schon mal machen aber du schreibst ja "viele" und das ist ein unnötiger Bremsklotz.

Zitat von sx2008:

Das merkt man dann wenn man das Projekt auf einem anderen Rechner kompilieren möchte wieviel Aufwand es bedeutet die ganzen projektspezifischen Komponenten zu synchronisieren und zu installieren.

Das kann ich ehrlich gesagt nicht nachvollziehen. Man hat ein Projekt und spezifische Komponenten. Man legt sich ein Package für die Komponenten an und nimmt dieses Package mit in die Projektgruppe auf. Dann schiebt man das Ganze auf den anderen Rechner, öffnet die Projektgruppe, sagt einmal "Alle Projekte erzeugen" und dann einmal "Installieren" beim Package.bpl in der Projektverwaltung. Voila... Fertig.

Zitat von sx2008:

Zitat von Codehunter:

viele selbst erstellte, spezialisierte Komponenten verwende...

Da fängt das Problem schon an.
Komponenten sollten so programmiert werden, dass sie universell einsetzbar sind. (wie die guten alten Legosteine aus den 80ern)
Wenn man Komponenten ganz speziell nur für ein Projekt entwickelt und diese in der IDE installiert tut man sich damit keinen Gefallen.
Das merkt man dann wenn man das Projekt auf einem anderen Rechner kompilieren möchte wieviel Aufwand es bedeutet die ganzen projektspezifischen Komponenten zu synchronisieren und zu installieren.

Ok, bei ein, zwei Komponenten kann man das schon mal machen aber du schreibst ja "viele" und das ist ein unnötiger Bremsklotz.

Das würde ich so auch nicht unterschreiben.
Das Package sollte unabhängig von anderen Packages oder Projekten sein. Es kann aber so spezifische Komponenten enthalten, dass man sie in nur in einem bestimmten Projekt verwenden will und muss. Entsprechend würden sie in anderen Projekten nur stören oder wenigstens überflüssig sein.

Ob es eine Lösung gibt, weiß ich aber nicht. Vielleicht in den Projektoptionen?

Zitat von Codehunter:

Das kann ich ehrlich gesagt nicht nachvollziehen. Man hat ein Projekt und spezifische Komponenten. Man legt sich ein Package für die Komponenten an ...

Eigentlich hat man ja das Projekt und dann noch ein 2. Projekt für die Unittests (oder hast du keine Unittests?).
Solange man alleine arbeitet bekommt man das noch gut geregelt; so wie du das beschrieben hast.
Aber im Team wird es schon schwieriger.
Unsere alte Versionsverwaltung (JediVCS) war z.B. ziemlich starr was die Pfade angeht.
Also blieben die Komponenten ausserhalb der Versionsverwaltung obwohl sie dazugehören.
Wenn ein Entwickler dann in einer Komponente einen Bugfix/eine Erweiterung vorgenommen hat, bedeutet das, dass er den Sourcecode per Mail an Alle verschickt hat mit Anweisungen was zu tun ist.

Wenn man gewohnt ist jedes Projekt einfach aus der Versionsverwaltung zu ziehen, dann sind solche Zusatzaufgaben doch recht störend.
Oder man zieht ein altes Projekt aus der Versionsverwaltung (der ursprüngliche Entwickler ist nicht mehr in der Firma) und dann stellt sich raus man muss noch 11 Komponenten installieren die aber irgendwo auf dem Fileserver liegen dann möchte man aber liebsten den Kopf auf den Tisch
Oder man holt eine alte Version eines Projekts und die Komponenten passen nicht zu dieser Version.
Weil Komponenten installiert werden müssen wird der schnelle Wechsel zwischen versch. Versionen behindert.

Im Team muss genau geregelt sein welche Komponenten benützt werden, wo sie liegen und jeder hat sie auf seinem Rechner installiert.
Diese Komponenten müssen Folgendes erfüllen:
* projektübergreifend einsetzbar
* hohe Qualität (keine Bugs, die die IDE gefährden)
* Zustand "mature"; also so gereift, dass nicht zu erwaten ist dass sich das Interface der Klassen noch gross ändert

Es ist sicher kein Fehler dies auch als Einzelkämpfer so zu handhaben und zumindest zu wissen dass projektspez. Komponenten zum Problem werden können.

Das trifft aber nur dann zu, wenn die Komponenten sozusagen "fixiert" sind. Also wenn man bei der Projektentwicklung davon ausgehen kann (oder muss) dass die Komponenten unveränderlich sind.

Ist ein Projekt so gestrickt, dass wesentliche Teile der Projektentwicklung innerhalb der Komponenten stattfindet, dann muss man die Komponenten-Units genauso mit verteilen (im SVN oder sonstwo) wie die Projekt-Units.

Entsprechend ist es sinnvoll, die Komponenten-Units in einem Package zu bündeln und dieses Package quasi mit der Projektgruppe zu "verheiraten". Das funktioniert in der Praxis bei uns auch sehr gut.

Es ist eben nur nervig wenn man mehrere Projekte betreut, dass man dann bei den anderen Projekten einen oder mehrere Reiter in der Tool-Palette hat, deren Komponenten in anderen Projekten nicht nur nutzlos wären sondern sogar kontraproduktiv.